Kubernetes Secret 的最佳實踐

在 Kubernetes 中，Secret 是一種儲存敏感資訊（例如密碼、OAuth 令牌和 SSH 金鑰）的物件。

Secret 使你能夠更好地控制敏感資訊的使用方式，並降低意外洩露的風險。Secret 值預設以 base64 字串編碼並以未加密方式儲存，但可以配置為靜態加密。

Pod 可以透過多種方式引用 Secret，例如作為卷掛載或環境變數。Secret 用於處理敏感資料，而ConfigMap 用於處理非敏感資料。

以下最佳實踐適用於叢集管理員和應用程式開發人員。請使用這些指南來提高 Secret 物件中敏感資訊的安全性，並更有效地管理你的 Secret。

叢集管理員

本節提供了叢集管理員可以用來提高叢集中機密資訊安全性的最佳實踐。

配置靜態加密

預設情況下，Secret 物件在 etcd 中以未加密形式儲存。你應該配置 etcd 中的 Secret 資料加密。有關說明，請參閱靜態加密 Secret 資料。

配置 Secret 的最小特權訪問

在規劃訪問控制機制（例如 Kubernetes 基於角色的訪問控制 (RBAC)）時，請考慮以下針對 Secret 物件的訪問指南。你還應遵循RBAC 最佳實踐中的其他指南。

• 元件：將 watch 或 list 訪問許可權僅限於最高特權的系統級元件。僅當元件的正常行為需要時，才授予 Secret 的 get 訪問許可權。
• 人類使用者：限制 Secret 的 get、watch 或 list 訪問許可權。僅允許叢集管理員訪問 etcd。這包括只讀訪問。對於更復雜的訪問控制，例如限制訪問具有特定註解的 Secret，請考慮使用第三方授權機制。

能夠建立使用 Secret 的 Pod 的使用者也可以檢視該 Secret 的值。即使叢集策略不允許使用者直接讀取 Secret，同一使用者也可能擁有執行 Pod 的許可權，而該 Pod 會暴露 Secret。你可以透過以下方法檢測或限制具有此訪問許可權的使用者有意或無意地暴露 Secret 資料所造成的影響。

• 使用短期 Secret
• 實施審計規則，對特定事件發出警報，例如單個使用者併發讀取多個 Secret

限制 Secret 的訪問許可權

使用單獨的名稱空間來隔離對掛載 Secret 的訪問。

改進 etcd 管理策略

考慮在 etcd 使用的持久儲存不再使用時將其擦除或銷燬。

如果存在多個 etcd 例項，請配置例項之間的加密 SSL/TLS 通訊，以保護傳輸中的 Secret 資料。

配置對外部 Secret 的訪問

你可以使用第三方 Secret 儲存提供商將你的敏感資料儲存在叢集之外，然後配置 Pod 來訪問這些資訊。Kubernetes Secret Store CSI Driver 是一個 DaemonSet，它允許 kubelet 從外部儲存中檢索 Secret，並將 Secret 作為卷掛載到你授權訪問資料的特定 Pod 中。

有關支援的提供商列表，請參閱Secret Store CSI Driver 的提供商。

使用交換記憶體的最佳實踐

有關為 Linux 節點設定交換記憶體的最佳實踐，請參閱交換記憶體管理。

開發者

本節提供了開發人員在構建和部署 Kubernetes 資源時，用來提高機密資料安全性的最佳實踐。

限制 Secret 訪問到特定容器

如果你在 Pod 中定義了多個容器，並且其中只有一個容器需要訪問某個 Secret，那麼請定義卷掛載或環境變數配置，以使其他容器無法訪問該 Secret。

讀取後保護 Secret 資料

應用程式在從環境變數或卷中讀取機密資訊的值後，仍需保護其安全。例如，你的應用程式必須避免以明文形式記錄 Secret 資料或將其傳輸給不受信任的第三方。

避免共享 Secret 清單

如果你透過清單配置 Secret，並以 base64 編碼 Secret 資料，那麼共享此檔案或將其簽入原始碼倉庫意味著所有能夠讀取該清單的人都可以訪問該 Secret。