文件

網路加密 (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 1.3

  • TLS_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_GCM_SHA256

  • 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 才能產生必要的憑證。

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 名稱 (例如 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 頁面

第三方憑證授權單位

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

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

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

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

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

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

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