网络加密 (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 密码套件。列表用 a 标记了推荐算法图标

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 **必须** 应用于其父节点的 hostname。如果没有通配符，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
```