文件

網路加密 (TLS)

MinIO 支援傳輸層安全 (TLS) 1.2+ 輸入和輸出流量加密。

SSL 已棄用

TLS 是安全通訊端層 (SSL) 加密的後繼者。SSL 已於 2018 年 6 月 30 日完全棄用

啟用 TLS

支援的密碼類型

MinIO 支援 Kubernetes 中的三種密碼類型。

  1. opaque

    使用 private.keypublic.crt 檔案。

  2. tls

    使用 tls.keytls.crt 檔案。

  3. 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_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_GCM_SHA256

  • TLS_AES_256_GCM_SHA384

  • 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 租戶時,MinIO Kubernetes Operator 可以自動產生 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 伺服器 Pod 上,以便所有 Pod 都有一致的一組受信任的 CA。

如果 MinIO 伺服器無法將傳入的用戶端 TLS 憑證發行者與任何可用的 CA 比對,則伺服器會拒絕連線,因為該連線無效。

自我簽署、內部、私有憑證,以及具有中繼憑證的公用 CA

如果使用非全域或非公用憑證授權單位發行的憑證部署 MinIO 租戶,或者如果使用需要使用中繼憑證的全域 CA,您必須向 Operator 提供這些 CA,以確保它可以信任這些憑證。

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

以下程序會將包含憑證授權單位 public.crt 的密碼附加到 MinIO Operator。您可以在單一憑證中指定多個 CA,只要您保持 BEGINEND 分隔符號不變即可。

  1. 建立 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 憑證。

  2. 重新啟動 Operator

    建立完成後,您必須重新啟動 Operator 才能載入新的 CA

    kubectl rollout restart deployments.apps/minio-operator -n minio-operator