文件

網路加密 (TLS)

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

SSL 已過時

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

啟用 TLS

支援的密鑰類型

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

  1. 不透明

    使用 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 Kubernetes Operator 可以在部署修改 MinIO 租用戶時自動產生 TLS 憑證。TLS 憑證產生過程如下:

  • Operator 會產生與租用戶相關聯的憑證簽署要求 (CSR)。CSR 包括租用戶服務和 Pod 的適當 DNS 主體替代名稱 (SAN)。

    然後,Operator 會等待CSR核准

  • CSR 會等待核准。如果已正確設定,Kubernetes TLS API 可以自動核准CSR。否則,叢集管理員必須先手動核准CSR,Kubernetes 才能產生必要的憑證。

  • Operator 會將產生的 TLS 憑證套用至 Tenant 中的每個 MinIO Pod。

Kubernetes TLS API 在產生新的 TLS 憑證時,會使用 Kubernetes 叢集憑證授權單位 (CA) 簽章演算法。請參閱支援的 TLS 加密套件,以取得 MinIO 支援的 TLS 加密套件和建議簽章演算法的完整列表。

預設情況下,Kubernetes 會將憑證套件放置在每個 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt。此 CA 套件應包含用於簽署 MinIO Tenant TLS 憑證的叢集或根 CA。部署在 Kubernetes 叢集中的其他應用程式可以信任此叢集憑證,以使用 MinIO 服務 DNS 名稱連線至 MinIO Tenant (例如,https://minio.minio-tenant-1.svc.cluster-domain.example:443)。

主體別名憑證

如果您有自訂的主體別名 (SAN) 憑證,且該憑證不是萬用字元憑證,則 TLS 憑證 SAN **必須**套用至其父節點的主機名稱。如果沒有萬用字元,SAN 必須完全符合才能連線至 Tenant。

使用 cert-manager 進行憑證管理

MinIO Operator 支援使用 cert-manager 完全取代其內建的自動憑證管理使用者驅動的手動憑證管理。有關使用 cert-manager 部署 MinIO Operator 和 Tenant 的說明,請參閱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 Tenant,使用需要使用中繼憑證的全球 CA,您必須向 Operator 提供這些 CA,以確保其可以信任這些憑證。

對於使用不受信任憑證部署的 Tenant,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