网络加密 (TLS)

MinIO 支持对传入和传出流量进行传输层安全 (TLS) 1.2+ 加密。

SSL 已被弃用

TLS 是安全套接字层 (SSL) 加密的后续版本。SSL 自 2018 年 6 月 30 日起已完全弃用。

启用 TLS

支持的密钥类型

MinIO 支持 Kubernetes 中的三种类型的密钥。

不透明

使用 private.key 和 public.crt 文件。
tls

使用 tls.key 和 tls.crt 文件。
cert-manager 1.7.x 或更高版本

在 Kubernetes 1.21 或更高版本上运行。

注意

为了获得对 *tls* 或 *cert-manager* 密钥的最佳支持，请升级到 5.0.10 或更高版本的运算符。

基于域的多个 TLS 证书

MinIO 运算符支持在部署或修改 MinIO 租户时附加用户指定的 TLS 证书。

这些自定义证书支持服务器名称指示 (SNI)，其中 MinIO 服务器根据连接客户端指定的 hostname 识别要使用的证书。例如，您可以生成由您组织的首选证书颁发机构 (CA) 签名的证书，并将这些证书附加到 MinIO 租户。信任该CA 的应用程序可以连接到 MinIO 租户并完全验证租户 TLS 证书。

支持的 TLS 密码套件

MinIO 建议生成 ECDSA（例如NIST P-256 曲线）或 EdDSA（例如Curve25519）TLS 私钥/证书，因为与 RSA 相比，它们的计算需求更低。

MinIO 支持以下由Go 支持的 TLS 1.2 和 1.3 密码套件。列表使用图标标记了推荐算法图标

TLS 1.3

TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384

TLS 1.2

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

对于具有有效TLS 集群签名证书的 Kubernetes 集群，MinIO Kubernetes 运算符可以在部署或修改 MinIO 租户时自动生成 TLS 证书。TLS 证书生成过程如下

操作员生成与租户关联的证书签名请求 (CSR)。CSR 包含租户服务和 Pod 的适当 DNS 主机名备用名称 (SAN)。

然后，操作员等待 CSR 批准。
CSR 等待批准。如果配置正确，Kubernetes TLS API 可以自动批准 CSR。否则，集群管理员必须手动批准 CSR，然后 Kubernetes 才能生成必要的证书。
操作员将生成的 TLS 证书应用于租户中的每个 MinIO Pod。

Kubernetes TLS API 在生成新 TLS 证书时使用 Kubernetes 集群证书颁发机构 (CA) 签名算法。有关 MinIO 支持的 TLS 密码套件和推荐签名算法的完整列表，请参阅支持的 TLS 密码套件。

默认情况下，Kubernetes 在每个 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 上放置一个证书包。此 CA 包应包含用于签署 MinIO 租户 TLS 证书的集群或根 CA。部署在 Kubernetes 集群中的其他应用程序可以使用此集群证书通过 MinIO 服务 DNS 名称（例如 https://minio.minio-tenant-1.svc.cluster-domain.example:443）连接到 MinIO 租户。

主体备用名称证书

如果您有一个自定义的主体备用名称 (SAN) 证书，该证书不是通配符证书，则 TLS 证书 SAN **必须**应用于其父节点的主机名。如果没有通配符，SAN 必须完全匹配才能连接到租户。

使用 cert-manager 进行证书管理

MinIO Operator 支持使用 cert-manager 作为其内置自动证书管理或用户驱动的手动证书管理的完整替代方案。有关使用 cert-manager 部署 MinIO Operator 和租户的说明，请参阅 cert-manager 页面。

第三方证书颁发机构

当部署或修改 MinIO 租户时，MinIO Kubernetes Operator 可以自动附加第三方证书颁发机构。

您可以随时添加、更新或从租户中删除 CA。您必须重新启动 MinIO 租户才能使对已配置 CA 的更改生效。

操作员将指定的 CA 放置在每个 MinIO Server Pod 上，以使所有 Pod 都具有一致的受信任 CA 集。

如果 MinIO Server 无法将传入客户端的 TLS 证书颁发者与任何可用 CA 匹配，则服务器会将连接拒绝为无效。

自签名、内部、私有证书以及具有中间证书的公共 CA

如果您使用非全局或非公共证书颁发机构签发的证书部署 MinIO 租户，或如果您使用需要使用中间证书的全局 CA，则必须将这些 CA 提供给操作员以确保它可以信任这些证书。

操作员可能会记录与使用不受信任的证书部署的租户的 TLS 证书验证相关的警告。

以下过程将包含证书颁发机构的 public.crt 的秘密附加到 MinIO Operator。您可以在单个证书中指定多个 CA，只要您保留 BEGIN 和 END 定界符即可。

创建 operator-ca-tls 秘密

以下在 MinIO Operator 命名空间 (minio-operator) 中创建 Kubernetes 秘密。
```
kubectl create secret generic operator-ca-tls \
   --from-file=public.crt -n minio-operator
```
public.crt 文件必须对应于包含一个或多个 CA 定义的有效 TLS 证书。
重新启动操作员

创建后，您必须重新启动操作员以加载新的 CA。
```
kubectl rollout restart deployments.apps/minio-operator -n minio-operator
```