網路加密 (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* 密碼的最佳支援，請升級到 Operator 版本 5.0.10 或更高版本。

多個基於網域的 TLS 憑證

當部署或修改 MinIO 租戶時，MinIO Operator 支援附加使用者指定的 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 Tenant TLS 憑證的叢集或根 CA。部署在 Kubernetes 叢集中的其他應用程式可以信任此叢集憑證，以使用 MinIO 服務 DNS 名稱（例如，https://minio.minio-tenant-1.svc.cluster-domain.example:443）連線到 MinIO Tenant。

主體別名憑證

如果您擁有自訂的主體別名 (SAN) 憑證，且該憑證並非萬用字元憑證，則 TLS 憑證的 SAN 必須適用於其父節點的主機名稱。如果不是萬用字元憑證，SAN 必須完全匹配才能連線到 Tenant。

使用 cert-manager 進行憑證管理

MinIO Operator 支援使用 cert-manager 作為其內建自動憑證管理或使用者驅動的手動憑證管理的完整替代方案。如需使用 cert-manager 部署 MinIO Operator 和 Tenants 的說明，請參閱cert-manager 頁面。

第三方憑證授權單位

當部署或修改 MinIO Tenant 時，MinIO Kubernetes Operator 可以自動附加第三方憑證授權單位。

您可以隨時新增、更新或移除 Tenant 中的 CA。您必須重新啟動 MinIO Tenant，才能套用已設定的 CA 變更。

Operator 會將指定的 CA 放置在每個 MinIO Server Pod 上，以便所有 Pod 都有一致的受信任 CA 集合。

如果 MinIO Server 無法將傳入用戶端的 TLS 憑證發行者與任何可用的 CA 相匹配，伺服器會拒絕該連線，並將其視為無效。

使用中繼憑證的自簽、內部、私有憑證和公用 CA

如果使用非全域或非公開憑證授權單位頒發的憑證部署 MinIO Tenants，或如果使用需要使用中繼憑證的全域 CA，您必須將這些 CA 提供給 Operator，以確保它可以信任這些憑證。

對於使用不受信任憑證部署的 Tenants，Operator 可能會記錄與 TLS 憑證驗證相關的警告。

下列程序會將包含憑證授權單位 public.crt 的 Secret 附加到 MinIO Operator。您可以在單一憑證中指定多個 CA，只要您保持 BEGIN 和 END 定界符不變即可。

建立 operator-ca-tls Secret

以下會在 MinIO Operator 命名空間 (minio-operator) 中建立 Kubernetes Secret。
```
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
```