这是本节的多页打印视图。 .
网络加密(TLS)
- 1: 为 Silo 启用 TLS
- 2: 为 Silo 启用多域 TLS
-
3: cert-manager
SSL 已弃用
TLS 是 Secure Socket Layer(SSL)加密的后继方案。 自 2018 年 6 月 30 日起,SSL 已被完全 弃用。
概览
MinIO 支持使用 Transport Layer Security (TLS) 1.2+ 对入站和出站流量进行加密。 MinIO 可以自动检测默认或自定义搜索路径中的证书,并为所有连接启用 TLS。 MinIO 支持客户端发起的 Server Name Indication (SNI) 请求,此时 MinIO 会尝试为客户端指定的主机名定位合适的 TLS 证书。
MinIO 至少 需要一张默认 TLS 证书,并且可以通过多张 TLS 证书支持 SNI 连接。 MinIO 使用 TLS Subject Alternative Name (SAN) 列表来判断应向客户端返回哪张证书。 如果 MinIO 找不到 SAN 覆盖客户端请求主机名的 TLS 证书,则会使用默认证书并尝试完成握手。
你可以指定一张 TLS 证书,覆盖 MinIO 部署可接受连接的所有 SAN。
这种配置所需设置最少,但会向连接客户端暴露 TLS SAN 中配置的全部主机名。 根据你的 TLS 配置,这些主机名可能包含内部或私有 SAN 域名。
你也可以按域名拆分配置多张 TLS 证书,并为所有未匹配主机名请求保留一张默认证书。 这种配置需要更多设置,但只会暴露返回证书的 TLS SAN 数组中所配置的主机名。
Kubernetes 上的 MinIO TLS
MinIO Kubernetes Operator 为 MinIO 租户提供三种 TLS 配置方式:
使用 Cluster Signing API 自动启用 TLS
对于具备有效 TLS Cluster Signing Certificate 的 Kubernetes 集群,MinIO Kubernetes Operator 可以在 部署 或 修改 MinIO 租户时自动生成 TLS 证书。
Kubernetes TLS API 在生成新的 TLS 证书时,会使用 Kubernetes 集群 Certificate Authority (CA) 的签名算法。 MinIO 支持的 TLS Cipher Suite 和推荐签名算法完整列表,请参见 支持的 TLS Cipher Suite。
默认情况下,Kubernetes 会在每个 pod 的
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt放置一份证书 bundle。 该 CA bundle 应包含用于签发 MinIO 租户 TLS 证书的集群 CA 或根 CA。 部署在同一 Kubernetes 集群中的其他应用,可以信任这份集群证书,并通过 MinIO service DNS 名称 连接到 MinIO 租户(例如https://minio.minio-tenant-1.svc.cluster-domain.example:443)。说明Subject Alternative Name 证书
如果你使用的是自定义 Subject Alternative Name (SAN) 证书,并且它 不是 通配符证书,那么 TLS 证书的 SAN 必须 覆盖其父节点主机名。 在没有通配符的情况下,SAN 必须精确匹配,才能成功连接到该租户。
cert-manager 证书管理
MinIO Operator 支持使用 cert-manager 作为其内置自动证书管理或用户手动证书管理的完整替代方案。 关于如何使用 cert-manager 部署 MinIO Operator 和租户,请参见 cert-manager 页面。
手动证书管理
Tenant CRD 规范中的
spec.externalCertsSecret支持引用类型为opaque或kubernetes.io/tls的 secret,其中包含用于 TLS 的private.key和public.crt。你可以指定多张证书,以支持分配了多个主机名的租户。
自签名、内部、私有证书以及带中间证书的公共 CA
如果你为 MinIO 租户部署的是由非全球或非公共 Certificate Authority 签发的证书,或者 使用了需要中间证书的公共 CA,则必须将这些 CA 提供给 Operator,以确保它能够信任这些证书。
对于使用不受信任证书部署的租户,Operator 可能会记录与 TLS 证书校验相关的警告。
以下过程会将一个包含 Certificate Authority public.crt 的 secret 挂载到 MinIO Operator。 你可以在同一证书文件中放入多个 CA,只要保持 BEGIN 和 END 分隔符原样不变即可。
-
创建
operator-ca-tlssecret以下命令会在 MinIO Operator 命名空间(
minio-operator)中创建一个 Kubernetes secret。public.crt文件必须是包含一个或多个 CA 定义的有效 TLS 证书。 -
重启 Operator
创建完成后,你必须重启 Operator 以加载新的 CA:
第三方 Certificate Authority
MinIO Kubernetes Operator 可以在 部署 或 修改 MinIO 租户时自动挂载第三方 Certificate Authority。
你可以随时为租户添加、更新或删除 CA。 要让配置中的 CA 变更生效,必须重启 MinIO 租户。
Operator 会将指定的 CA 放置到每个 MinIO Server pod 上,从而确保所有 pod 拥有一致的受信任 CA 集合。
如果 MinIO Server 无法将传入客户端的 TLS 证书签发者与任一可用 CA 匹配,则会将该连接视为无效并拒绝。
裸金属上的 MinIO TLS
MinIO Server 会为每个节点搜索 TLS 私钥和证书,并使用这些凭据启用 TLS。 MinIO 会在发现并验证证书后自动启用 TLS。 搜索位置取决于你的 MinIO 配置:
默认情况下,MinIO server 会在以下目录中查找每个节点的 TLS 私钥和证书:
其中 ${HOME} 是运行 MinIO 服务端进程的用户主目录。 如果 ${HOME}/.minio/certs 目录不存在,你可能需要手动创建它。
对于由 systemd 管理的部署,该路径必须对应运行 MinIO 进程的 USER。 如果该用户没有主目录,请改用 自定义路径 选项。
你可以通过 minio server --certs-dir 或 -S 参数指定 MinIO server 搜索证书的路径。
例如,以下命令片段指示 MinIO 进程使用 /opt/minio/certs 目录存放 TLS 证书。
运行 MinIO service 的用户 必须 对该目录拥有读写权限。
请将默认域名(例如 minio.example.net)对应的 TLS 证书放入 /certs 目录,其中私钥命名为 private.key,公钥证书命名为 public.crt。
对于分布式 MinIO 部署,部署中的每个节点都必须具有一致的 TLS 证书配置。
自签名、内部、私有证书以及带中间证书的公共 CA
如果你使用的是由非全球或非公共 Certificate Authority 签发的证书,或者 使用了需要中间证书的公共 CA,则必须将这些 CA 提供给 MinIO Server。 如果 MinIO server 不具备这些必要 CA,在连接其他服务时可能会返回与 TLS 校验相关的警告或错误。
请将 CA 证书放入 /certs/CAs 目录。 该目录的根路径取决于你使用的是默认证书路径,还是自定义证书路径(minio server --certs-dir 或 -S)。
以下示例假设 MinIO Server 以 --certs dir /opt/minio/certs 启动:
对于自签名证书,Certificate Authority 通常就是用于签署该证书的私钥。
对于由内部、私有或其他非全球 Certificate Authority 签发的证书,请使用签发该证书的同一 CA。 非全球 CA 必须包含从中间证书到根证书的完整信任链。
如果提供的文件不是 X.509 证书,MinIO 会忽略它,并可能在校验由该 CA 签发的证书时返回错误。
第三方 Certificate Authority
MinIO Server 会使用主机系统中的受信任根证书存储来校验每个连接客户端提交的 TLS 证书。
请将 CA 证书放入 /certs/CAs 目录。 该目录的根路径取决于你使用的是默认证书路径,还是自定义证书路径(minio server --certs-dir 或 -S)。
以下示例假设 MinIO Server 以 --certs dir /opt/minio/certs 启动:
请将每个 CA 的证书文件放入 /CAs 子目录。 确保 MinIO 部署中的所有主机在该目录下拥有一致的受信任 CA 集合。 如果 MinIO Server 无法将传入客户端的 TLS 证书签发者与任一可用 CA 匹配,则会将该连接视为无效并拒绝。
支持的 TLS Cipher Suite
与 RSA 相比,MinIO 更推荐生成 ECDSA(例如 NIST P-256 曲线)或 EdDSA(例如 Curve25519)TLS 私钥/证书,因为它们的计算开销更低。
MinIO 支持以下由 Go 支持的 TLS 1.2 和 TLS 1.3 cipher suite。列表中使用 标记推荐算法:
TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
1 - 为 Silo 启用 TLS
MinIO 支持使用 Transport Layer Security (TLS) 1.2+ 对入站和出站流量进行加密。
MinIO Operator 支持通过以下方式为 MinIO 租户启用 TLS:
- 使用 Kubernetes Cluster Signing Certificates 自动下发 TLS
- 使用 Kubernetes secret 指定用户提供的 TLS
- 使用 cert-manager 管理 TLS 证书
MinIO 会自动检测配置目录或默认目录中的 TLS 证书,并以启用 TLS 的方式启动。
本文说明如何为 MinIO 的单个域名启用 TLS。需要通过 SNI 服务多个主机名时,请参阅多域 TLS 指南。
前提条件
访问 MinIO 集群
你必须能够访问 Kubernetes 集群,并且 kubectl 配置中具备对应的管理权限。
本过程假设你的权限足以在 Kubernetes 集群中部署或修改 MinIO 相关资源,包括但不限于 pod、statefulset、replicaset、deployment 和 secret。
本过程使用 mc 对 MinIO 集群执行操作。 请在一台可通过网络访问该集群的机器上安装 mc。 关于下载和安装 mc,请参见 mc Installation Quickstart。
本过程还假设你已经为 MinIO 集群配置了 alias。
同时假设你拥有对每台 MinIO 主机服务器的 SSH 或类似 shell 级别的管理访问权限。
TLS 证书
请准备 MinIO 所需的 TLS 证书,并确保其使用 受支持的密码套件。
关于支持的租户 TLS 配置,请参见 Kubernetes 上的 MinIO TLS。
请按你偏好的方式准备证书,例如通过组织内部 Certificate Authority,或使用 Digicert、Verisign 等知名公共 CA 提供商。
你也可以使用 openssl 或 MinIO 的 certgen 工具创建自签名证书。
例如,以下命令会生成一个自签名证书,其中包含与 MinIO 服务端 主机关联的一组 IP 和 DNS Subject Alternative Name (SAN):
关于证书生成和放置方式的更完整说明,请参见 裸金属上的 MinIO TLS。
步骤
MinIO Operator 支持通过三种方式管理 MinIO 租户上的 TLS 证书:
- MinIO 自动生成 TLS 证书
- 由
cert-manager管理的 TLS 证书 - 用户自行管理的 TLS 证书
你可以组合使用上述任意方式来启用和配置 TLS。 对于用户自有证书,MinIO 强烈建议使用 cert-manager 以简化管理和续期流程。
你也可以部署未启用 TLS 的 MinIO 租户。
以下步骤同时适用于使用 Kustomize 的新建和现有 MinIO 部署:
-
检查 Tenant CRD 中的
TenantSpec.requestAutoCert和TenantSpec.certConfig字段。对于现有 MinIO 租户,请检查用于创建租户的 Kustomize 资源,并查看这些字段及其当前配置(如果已配置)。
-
按需创建或修改租户 YAML,设置
requestAutoCert和certConfig的值。 例如:创建或修改租户资源时,可参考 固定到
v7.1.1的 Kustomize Tenant base YAML 作为基线模板。 -
应用新的 Kustomization 模板
一旦应用这些更改,MinIO Operator 会使用更新后的配置自动重新部署该租户。
以下步骤同时适用于使用 Kustomize 的新建和现有 MinIO 部署:
-
检查 Tenant CRD 中的
TenantSpec.externalCertsCecret字段对于现有 MinIO 租户,请检查用于创建租户的 Kustomize 资源,并查看该字段当前配置(如果已配置)。
-
创建或修改租户 YAML,使其引用适当的
cert-manager资源。例如,以下租户 YAML 片段引用了一个名为
myminio-tls的 cert-manager 资源: -
应用新的 Kustomization 模板
一旦应用这些更改,MinIO Operator 会使用更新后的配置自动重新部署该租户。
以下步骤同时适用于使用 Kustomize 的新建和现有 MinIO 部署:
-
检查 Tenant CRD 中的
TenantSpec.externalCertSecret字段。对于现有 MinIO 租户,请检查用于创建租户的 Kustomize 资源,并查看该字段当前配置(如果已配置)。
-
创建或修改租户 YAML,使其引用一个类型为
kubernetes.io/tls的 secret:例如,以下租户 YAML 片段引用了一个 TLS secret,它覆盖了 MinIO 租户接受连接时使用的域名。
-
应用新的 Kustomization 模板
一旦应用这些更改,MinIO Operator 会使用更新后的配置自动重新部署该租户。
MinIO Server 会为每个节点搜索 TLS 私钥和证书,并使用这些凭据启用 TLS。 MinIO 会在发现并验证证书后自动启用 TLS。 搜索位置取决于你的 MinIO 配置:
默认情况下,MinIO server 会在以下目录中查找每个节点的 TLS 私钥和证书:
其中 ${HOME} 是运行 MinIO 服务端进程的用户主目录。 如果 ${HOME}/.minio/certs 目录不存在,你可能需要手动创建它。
对于由 systemd 管理的部署,该路径必须对应运行 MinIO 进程的 USER。 如果该用户没有主目录,请改用 Custom Path 选项。
你可以通过 minio server --certs-dir 或 -S 参数指定 MinIO server 搜索证书的路径。
例如,以下命令片段指示 MinIO 进程使用 /opt/minio/certs 目录存放 TLS 证书。
运行 MinIO service 的用户 必须 对该目录拥有读写权限。
请将默认域名(例如 minio.example.net)对应的 TLS 证书放入 /certs 目录,其中私钥命名为 private.key,公钥证书命名为 public.crt。
例如:
你可以使用 MinIO 的 certgen 生成自签名证书,以便在启用 TLS 的情况下评估 MinIO。 例如,以下命令会生成一个自签名证书,其中包含与 MinIO 服务端 主机关联的一组 IP 和 DNS Subject Alternative Name (SAN):
请将生成的 public.crt 和 private.key 放入 /path/to/certs 目录,以便为 MinIO 部署启用 TLS。 应用可以将 public.crt 作为受信任的 Certificate Authority 使用,从而在不禁用证书校验的情况下连接到 MinIO 部署。
如果你是在重新配置一个此前未启用 TLS 的现有部署,请更新 MINIO_VOLUMES,将其中的 http 改为 https。 你可能还需要同步更新应用或客户端所使用的 URL。
2 - 为 Silo 启用多域 TLS
MinIO 支持使用 Transport Layer Security (TLS) 1.2+ 对入站和出站流量进行加密。
MinIO Operator 支持通过以下方式为 MinIO 租户启用 TLS:
- 使用 Kubernetes Cluster Signing Certificates 自动下发 TLS
- 使用 Kubernetes secret 指定用户自有 TLS
- 使用 cert-manager 管理 TLS 证书
MinIO Operator 支持在 部署 或 修改 MinIO 租户时挂载用户指定的 TLS 证书。
这些自定义证书支持 Server Name Indication (SNI),即 MinIO server 会根据客户端指定的主机名决定使用哪张证书。 例如,你可以生成由组织内首选 Certificate Authority (CA) 签发的证书,并将其挂载到 MinIO 租户上。 信任该 CA 的应用可以连接到 MinIO 租户,并完整校验其 TLS 证书。
MinIO 会自动检测配置目录或默认目录中的 TLS 证书,并在启用 TLS 的情况下启动。
MinIO server 支持多张 TLS 证书,server 会使用 Server Name Indication (SNI) 来识别在响应客户端请求时应当使用哪张证书。 当客户端使用特定主机名连接时,MinIO 会通过 SNI 选择与该主机名匹配的 TLS 证书。
本文说明如何为 MinIO 启用多域 TLS。部署只服务一个主机名时,请参阅单域 TLS 指南。
前提条件
访问 MinIO 集群
你必须能够访问 Kubernetes 集群,并且 kubectl 配置中具备对应的管理权限。
本过程假设你的权限足以在 Kubernetes 集群中部署或修改 MinIO 相关资源,包括但不限于 pod、statefulset、replicaset、deployment 和 secret。
本过程使用 mc 对 MinIO 集群执行操作。 请在一台可通过网络访问该集群的机器上安装 mc。 关于下载和安装 mc,请参见 mc Installation Quickstart。
本过程还假设你已经为 MinIO 集群配置了 alias。
同时假设你拥有对每台 MinIO 主机 server 的 SSH 或类似 shell 级别的管理访问权限。
TLS 证书
请准备 MinIO 所需的 TLS 证书,并确保其使用 受支持的密码套件。
关于支持的租户 TLS 配置,请参见 Kubernetes 上的 MinIO TLS。
请按你偏好的方式准备证书,例如通过组织内部 Certificate Authority,或使用 Digicert、Verisign 等知名公共提供商。
你也可以使用 openssl 或 MinIO 的 certgen 工具创建自签名证书。
例如,以下命令会生成一个自签名证书,其中包含与 MinIO 服务端 主机关联的一组 IP 和 DNS Subject Alternative Name (SAN):
关于证书生成和放置方式的更完整说明,请参见 裸金属上的 MinIO TLS。
步骤
MinIO Operator 支持通过三种方式管理 MinIO 租户上的 TLS 证书:
- MinIO 自动生成 TLS 证书
- 用户指定的 TLS 证书
- 由
cert-manager管理的 TLS 证书
你也可以部署未启用 TLS 的 MinIO 租户。
以下步骤同时适用于使用 Kustomize 的新建和现有 MinIO 部署:
-
检查 Tenant CRD 中的
TenantSpec.requestAutoCert和TenantSpec.certConfig字段。对于现有 MinIO 租户,请检查用于创建租户的 Kustomize 资源,并查看这些字段及其当前配置(如果已配置)。
-
按需创建或修改租户 YAML,设置
requestAutoCert和certConfig的值。 例如:spec.certConfig.dnsNames应包含 TLS 证书所覆盖的 SAN 列表。创建或修改租户资源时,可参考 固定到
v7.1.1的 Kustomize Tenant base YAML 作为基线模板。 -
应用新的 Kustomization 模板
一旦应用这些更改,MinIO Operator 会使用更新后的配置自动重新部署该租户。
以下步骤同时适用于使用 Kustomize 的新建和现有 MinIO 部署:
-
检查 Tenant CRD 中的
TenantSpec.externalCertsCecret字段对于现有 MinIO 租户,请检查用于创建租户的 Kustomize 资源,并查看该字段当前配置(如果已配置)。
-
创建或修改租户 YAML,使其引用适当的
cert-manager资源。例如,以下租户 YAML 片段引用了一个名为
myminio-tls的 cert-manager 资源: -
应用新的 Kustomization 模板
一旦应用这些更改,MinIO Operator 会使用更新后的配置自动重新部署该租户。
以下步骤同时适用于使用 Kustomize 的新建和现有 MinIO 部署:
-
检查 Tenant CRD 中的
TenantSpec.externalCertSecret字段。对于现有 MinIO 租户,请检查用于创建租户的 Kustomize 资源,并查看该字段当前配置(如果已配置)。
-
创建或修改租户 YAML,使其引用一个类型为
kubernetes.io/tls的 secret:例如,以下租户 YAML 片段为 MinIO 租户可接受连接的每个域名引用了两份 TLS secret:
-
应用新的 Kustomization 模板
一旦应用这些更改,MinIO Operator 会使用更新后的配置自动重新部署该租户。
MinIO Server 会为每个节点搜索 TLS 私钥和证书,并使用这些凭据启用 TLS。 MinIO 会在发现并验证证书后自动启用 TLS。 搜索位置取决于你的 MinIO 配置:
默认情况下,MinIO server 会在以下目录中查找每个节点的 TLS 私钥和证书:
其中 ${HOME} 是运行 MinIO 服务端进程的用户主目录。 如果 ${HOME}/.minio/certs 目录不存在,你可能需要手动创建它。
对于由 systemd 管理的部署,该路径必须对应运行 MinIO 进程的 USER。 如果该用户没有主目录,请改用 Custom Path 选项。
你可以通过 minio server --certs-dir 或 -S 参数指定 MinIO server 搜索证书的路径。
例如,以下命令片段指示 MinIO 进程使用 /opt/minio/certs 目录存放 TLS 证书。
运行 MinIO service 的用户 必须 对该目录拥有读写权限。
请将证书放入 /certs 目录,并为 MinIO 需要呈现 TLS 证书的每个附加域名在 /certs 下创建一个子目录。 虽然 MinIO 对目录名称没有强制要求,但建议将子目录命名为对应域名,以便人工识别。 请将该域名的 TLS 私钥和公钥证书放入对应子目录中。
3 - cert-manager
使用 cert-manager 管理 TLS 证书
本指南介绍如何安装 cert-manager 以管理 TLS 证书。 本文假设你使用的是全新或刚初始化的 MinIO Operator 安装环境。
说明
本指南使用自签名 ClusterIssuer。 你也可以使用 cert-manager 支持的其他 Issuer。
主要区别在于,你必须向 MinIO 提供该 Issuer 的 CA 证书,而不是本文中提到的这些 CA。
如需更高级的配置,请参考 cert-manager 文档 以及你所在组织的证书规范。
cert-manager 负责管理 Kubernetes 集群中的证书。 MinIO Operator 支持使用 cert-manager 来管理和签发证书,作为 Operator 自行管理自身及其租户证书的替代方案。
cert-manager 从 Issuer 或 ClusterIssuer 获取有效证书,并能在证书过期前自动续期。
ClusterIssuer 可为多个命名空间签发证书。 Issuer 只能为其所在命名空间签发证书。
下图展示了 cert-manager 如何在 Kubernetes 集群的不同命名空间中提供证书。
ClusterIssuer位于 Kubernetes 集群的根级别,通常在default命名空间中,用于向其他所有命名空间提供证书。minio-operator命名空间拥有其本地Issuer。- 每个租户命名空间也拥有其本地
Issuer。 - 各租户命名空间签发的证书必须被 MinIO Operator 感知并信任。
前提条件
- 使用受支持版本的 Kubernetes
- 已安装 kustomize
- 可通过
kubectl访问你的k8s集群
配置 cert-manager
安装 cert-manager
以下命令使用 kubectl 安装 1.12.13 版本。
推荐使用 Release 1.12.X LTS,但你也可以安装最新版本。 有关安装 cert-manager 的更多细节,请参见其 installation instructions。
为集群创建自签名 ClusterIssuer
ClusterIssuer 是集群中的顶层 Issuer,其他所有证书都从它派生。
-
创建一个
ClusterIssuer资源,请求 cert-manager 生成该对象。创建一个名为
selfsigned-root-clusterissuer.yaml的文件,内容如下: -
将该资源应用到集群: