网络加密 (TLS)

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

SSL 已弃用

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

启用 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 或更高版本的 Operator。

基于多个域的 TLS 证书

当部署或修改 MinIO 租户时，MinIO Operator 支持附加用户指定的 TLS 证书。

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

支持的 TLS 密码套件

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

MinIO 支持以下 TLS 1.2 和 1.3 密码套件，如Go 所支持。列表使用一个图标标记推荐的算法图标

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 运营商支持使用cert-manager完全替换其内置的自动证书管理或用户驱动的证书手动管理。有关使用 cert-manager 部署 MinIO 运营商和租户的说明，请参阅cert-manager 页面。

第三方证书颁发机构

MinIO Kubernetes 运营商可以在部署或修改 MinIO 租户时自动附加第三方证书颁发机构。

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

运营商将指定的 CA 放置在每个 MinIO Server Pod 上，以便所有 Pod 都具有一致的受信任 CA 集。

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

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

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

对于使用不受信任的证书部署的租户，运营商可能会记录与 TLS 证书验证相关的警告。

以下过程将包含证书颁发机构的public.crt的密钥附加到 MinIO 运营商。您可以在单个证书中指定多个 CA，只要您按原样保留BEGIN和END分隔符即可。

创建operator-ca-tls密钥

以下操作将在 MinIO 运营商命名空间 (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
```