网络加密 (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 或更高版本的运算符。

基于多个域的 TLS 证书

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

这些自定义证书支持服务器名称指示 (SNI)，其中 MinIO 服务器根据连接客户端指定的主机名识别要使用的证书。例如，您可以生成由贵组织首选的证书颁发机构 (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 Operator可以在部署或修改MinIO租户时自动生成TLS证书。TLS证书生成过程如下所示

Operator会生成与租户关联的证书签名请求（CSR）。CSR包含租户服务和Pod的相应DNS主题备用名称（SAN）。

然后，Operator等待CSR批准。
CSR等待批准。如果配置正确，Kubernetes TLS API可以自动批准CSR。否则，集群管理员必须手动批准CSR，然后Kubernetes才能生成必要的证书。
Operator将生成的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 Kubernetes Operator可以在部署或修改MinIO租户时自动附加第三方证书颁发机构。

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

Operator将指定的CA放置在每个MinIO Server Pod上，以便所有Pod都具有相同的一组受信任CA。

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

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

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

对于使用不受信任的证书部署的租户，Operator可能会记录与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证书。
重新启动Operator

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