网络加密 (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 服务器根据连接客户端指定的 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