网络加密 (TLS)
SSL 已弃用
TLS 是安全套接字层 (SSL) 加密的继任者。截至 2018 年 6 月 30 日，SSL 已被完全弃用。
概述
MinIO 支持对传入和传出流量进行传输层安全 (TLS) 1.2+ 加密。MinIO 可以自动检测指定到默认或自定义搜索路径的证书，并为所有连接启用 TLS。MinIO 支持来自客户端的服务器名称指示 (SNI) 请求，MinIO 会尝试为客户端指定的主机名找到合适的 TLS 证书。
MinIO 至少需要一个默认的 TLS 证书，并且可以支持多个 TLS 证书以支持 SNI 连接。MinIO 使用 TLS 主题备用名称 (SAN) 列表来确定要返回给客户端的证书。如果 MinIO 找不到其 SAN 覆盖客户端请求主机名的 TLS 证书，MinIO 会使用默认证书并尝试建立握手。
您可以指定一个覆盖 MinIO 部署接受连接的所有可能 SAN 的单一 TLS 证书。
这种配置需要的配置最少，但必然会向连接的客户端暴露 TLS SAN 中配置的所有主机名。根据您的 TLS 配置，这可能包括内部或私有 SAN 域。
您也可以指定由域分隔的多个 TLS 证书，并为任何不匹配的主机名请求提供一个默认证书。这种配置需要更多的配置，但只暴露那些在返回的 TLS SAN 数组中配置的主机名。
Kubernetes 上的 MinIO TLS
MinIO Kubernetes Operator 提供了三种在 MinIO Tenant 上配置 TLS 的方法
- 使用集群签名 API 的自动 TLS
对于具有有效TLS 集群签名证书的 Kubernetes 集群，MinIO Kubernetes Operator 可以在部署或修改 MinIO Tenant 时自动生成 TLS 证书。
Kubernetes TLS API 在生成新的 TLS 证书时使用 Kubernetes 集群证书颁发机构 (CA) 签名算法。有关 MinIO 支持的 TLS 密码套件和推荐的签名算法的完整列表，请参阅支持的 TLS 密码套件。
默认情况下，Kubernetes 在每个 pod 的
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt处放置一个证书包。此 CA 包应包括用于签署 MinIO Tenant TLS 证书的集群或根 CA。部署在 Kubernetes 集群中的其他应用程序可以信任此集群证书，以使用 MinIO 服务 DNS 名称（例如https://minio.minio-tenant-1.svc.cluster-domain.example:443）连接到 MinIO Tenant。主题备用名称证书
如果您有自定义的主题备用名称 (SAN) 证书，但它不是通配符证书，那么 TLS 证书的 SAN 必须适用于其父节点的主机名。如果没有通配符，SAN 必须精确匹配才能连接到租户。
- cert-manager 证书管理
MinIO Operator 支持使用 cert-manager 来完全替代其内置的自动证书管理或用户驱动的手动证书管理。有关使用 cert-manager 部署 MinIO Operator 和租户的说明，请参阅 cert-manager 页面。
- 手动证书管理
- Tenant CRD 规范
spec.externalCertsSecret支持 .. include:: /includes/common/common-configure-keycloak-identity-management.rst - start-after:
start-configure-keycloak-minio-cli
orts 指定
opaque或kubernetes.io/tls类型的机密，其中包含用于 TLS 的private.key和public.crt。
您可以指定多个证书以支持具有多个分配主机名的租户。
- Tenant CRD 规范
自签名、内部、私有证书以及带有中间证书的公共 CA
如果部署的 MinIO Tenant 使用由非全局或非公共证书颁发机构颁发的证书，或者如果使用需要中间证书的全局 CA，您必须将这些 CA 提供给 Operator 以确保它能够信任这些证书。
对于使用不受信任证书部署的 Tenant，Operator 可能会记录与 TLS 证书验证相关的警告。
以下过程将包含证书颁发机构的 public.crt 的 secret 附加到 MinIO Operator。您可以在一个证书中指定多个 CA，只要保持 BEGIN 和 END 分隔符不变即可。
创建
operator-ca-tlssecret以下操作在 MinIO Operator 命名空间 (
minio-operator) 中创建一个 Kubernetes secret。kubectl create secret generic operator-ca-tls \ --from-file=public.crt -n minio-operator
public.crt文件必须对应于一个有效的 TLS 证书，其中包含一个或多个 CA 定义。重启 Operator
创建后，您必须重启 Operator 以加载新的 CA
kubectl rollout restart deployments.apps/minio-operator -n minio-operator
裸机上的 MinIO TLS
MinIO Server 会为每个节点搜索 TLS 密钥和证书，并使用这些凭据来启用 TLS。MinIO 在发现并验证证书后会自动启用 TLS。搜索位置取决于您的 MinIO 配置
默认情况下，MinIO 服务器在以下目录中查找每个节点的 TLS 密钥和证书
${HOME}/.minio/certs
其中 ${HOME} 是运行 MinIO Server 进程的用户的家目录。如果 ${HOME}/.minio/certs 目录不存在，您可能需要创建它。
对于由 systemd 管理的部署，这必须对应于运行 MinIO 进程的 USER。如果该用户没有家目录，请改用自定义路径选项。
您可以使用 minio server --certs-dir 或 -S 参数指定 MinIO 服务器搜索证书的路径。
例如，以下命令片段指示 MinIO 进程使用 /opt/minio/certs 目录来存放 TLS 证书。
minio server --certs-dir /opt/minio/certs ...
运行 MinIO 服务的用户必须对此目录具有读写权限。
将默认域（例如 minio.example.net）的 TLS 证书放置在 /certs 目录中，私钥为 private.key，公共证书为 public.crt。
对于分布式 MinIO 部署，部署中的每个节点都必须具有匹配的 TLS 证书配置。
自签名、内部、私有证书以及带有中间证书的公共 CA
如果使用由非全局或非公共证书颁发机构签名的证书，或者如果使用需要中间证书的全局 CA，您必须将这些 CA 提供给 MinIO Server。如果 MinIO 服务器没有必要的 CA，它在连接到其他服务时可能会返回与 TLS 验证相关的警告或错误。
将 CA 证书放置在 /certs/CAs 文件夹中。此文件夹的根路径取决于您是使用默认证书路径还是自定义证书路径（minio server --certs-dir 或 -S）
mv myCA.crt ${HOME}/.minio/certs/CAs
以下示例假设 MinIO Server 是用 --certs dir /opt/minio/certs 启动的
mv myCA.crt /opt/minio/certs/CAs/
对于自签名证书，证书颁发机构通常是用于签署该证书的私钥。
对于由内部、私有或其他非全局证书颁发机构签名的证书，请使用签署该证书的相同 CA。非全局 CA 必须包括从中间证书到根证书的完整信任链。
如果提供的文件不是 X.509 证书，MinIO 会忽略它，并可能在验证由该 CA 签名的证书时返回错误。
第三方证书颁发机构
MinIO Server 会根据主机系统的受信任根证书存储来验证每个连接客户端提供的 TLS 证书。
将 CA 证书放置在 /certs/CAs 文件夹中。此文件夹的根路径取决于您是使用默认证书路径还是自定义证书路径（minio server --certs-dir 或 -S）
mv myCA.crt ${HOME}/certs/CAs
以下示例假设 MinIO Server 是用 --certs dir /opt/minio/certs 启动的
mv myCA.crt /opt/minio/certs/CAs/
将每个 CA 的证书文件放入 /CAs 子目录中。确保 MinIO 部署中的所有主机在该目录中都有一组一致的受信任 CA。如果 MinIO Server 无法将传入客户端的 TLS 证书颁发者与任何可用的 CA 匹配，服务器将拒绝该连接并视其为无效。
支持的 TLS 密码套件
MinIO 推荐生成 ECDSA（例如 NIST P-256 曲线）或 EdDSA（例如 Curve25519）TLS 私钥/证书，因为与 RSA 相比，它们的计算要求更低。
MinIO 支持 Go 所支持的以下 TLS 1.2 和 1.3 密码套件。列表中推荐的算法用一个图标标记
TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
