Kubernetes 密鑰 (Secrets) 的良好實務

在 Kubernetes 中，密鑰 (Secret) 是一個物件，用於儲存敏感資訊，例如密碼、OAuth 權杖與 SSH 金鑰。

密鑰 (Secrets) 讓您更能控制敏感資訊的使用方式，並降低意外洩露的風險。密鑰值編碼為 base64 字串，預設為未加密儲存，但可以設定為靜態加密。

Pod 可以透過多種方式參考密鑰 (Secret)，例如在磁碟區掛載中或作為環境變數。密鑰 (Secrets) 設計用於機密資料，而 ConfigMaps 設計用於非機密資料。

以下良好實務旨在供叢集管理員與應用程式開發人員使用。使用這些指南來改善密鑰 (Secret) 物件中敏感資訊的安全性，並更有效率地管理您的密鑰 (Secrets)。

叢集管理員

本節提供叢集管理員可以使用的良好實務，以改善叢集中機密資訊的安全性。

設定靜態加密

預設情況下，Secret 物件會以未加密方式儲存在 etcd 中。你應該設定加密你的 Secret 資料在 etcd 中。如需操作說明，請參閱加密靜態 Secret 資料。

設定最小權限存取 Secrets

當你規劃存取控制機制時，例如 Kubernetes 基於角色的存取控制 (RBAC)，請考量以下針對 Secret 物件存取的指引。你也應該遵循RBAC 良好實務中的其他指引。

• 組件：限制 watch 或 list 存取權僅限於最受信任的系統層級組件。僅在組件的正常行為需要時，才授予 Secrets 的 get 存取權。
• 人員：限制對 Secrets 的 get、watch 或 list 存取權。僅允許叢集管理員存取 etcd。這包括唯讀存取權。對於更複雜的存取控制，例如限制對具有特定註釋的 Secrets 的存取，請考慮使用第三方授權機制。

可以建立使用 Secret 的 Pod 的使用者，也可以看到該 Secret 的值。即使叢集策略不允許使用者直接讀取 Secret，同樣的使用者仍然可以存取執行 Pod，進而暴露 Secret。你可以偵測或限制 Secret 資料被暴露所造成的影響，不論是有意或無意，只要使用者擁有此存取權。一些建議包括

• 使用生命週期短的 Secrets
• 實作稽核規則，以針對特定事件發出警示，例如單一使用者同時讀取多個 Secrets

限制 Secrets 的存取權

使用獨立的命名空間來隔離對已掛載 Secret 的存取。

改善 etcd 管理策略

考慮抹除或粉碎 etcd 使用的持久儲存空間，一旦不再使用。

如果有多個 etcd 實例，設定實例之間加密的 SSL/TLS 通訊，以保護傳輸中的 Secret 資料。

設定對外部 Secrets 的存取

你可以使用第三方 Secrets 儲存提供者，將你的機密資料保存在叢集外部，然後設定 Pod 以存取該資訊。Kubernetes Secrets Store CSI 驅動程式是一個 DaemonSet，可讓 kubelet 從外部儲存區檢索 Secrets，並將 Secrets 掛載為磁碟區到特定的 Pod 中，你授權這些 Pod 存取資料。

如需支援的提供者清單，請參閱Secret Store CSI 驅動程式的提供者。

開發人員

本節提供良好實務，供開發人員使用，以改善在建置和部署 Kubernetes 資源時的機密資料安全性。

限制 Secret 存取權給特定容器

如果你在 Pod 中定義多個容器，且只有其中一個容器需要存取 Secret，請定義磁碟區掛載或環境變數設定，讓其他容器無法存取該 Secret。

讀取後保護 Secret 資料

應用程式在從環境變數或磁碟區讀取機密資訊後，仍然需要保護其值。例如，你的應用程式必須避免以明文記錄 Secret 資料或將其傳輸給不受信任的對象。

避免分享 Secret 清單

如果你透過清單設定 Secret，並將 Secret 資料編碼為 base64，分享此檔案或將其簽入原始碼儲存庫，表示任何可以讀取清單的人都可以取得 Secret。