強制實施 Pod 安全標準

本頁面提供關於強制實施 Pod 安全標準 的最佳實務概述。

使用內建的 Pod 安全存取控制器

Pod 安全存取控制器 旨在取代已棄用的 PodSecurityPolicies。

配置所有叢集命名空間

完全沒有任何配置的命名空間，應被視為叢集安全模型中的重大漏洞。 我們建議花時間分析每個命名空間中執行的工作負載類型， 並參考 Pod 安全標準為其中每一個決定合適的層級。未被標籤的命名空間應僅代表它尚未被評估。

在所有命名空間中的所有工作負載都具有相同安全需求的情境下， 我們提供了一個範例， 說明如何批量套用 PodSecurity 標籤。

採用最小權限原則

在理想的情況下，每個命名空間中的每個 Pod 都應符合 restricted 政策的要求。 然而，這既不可能也不切實際，因為某些工作負載基於合理的理由仍需要提升權限。

• 允許 privileged 工作負載的命名空間，應建立並強制實施適當的存取控制。
• 對於在這些權限較為寬鬆的命名空間中執行的工作負載，應維護關於其獨特安全需求的文件。 若情況允許，應考量該如何進一步限制這些需求。

採用多重模式策略

Pod 安全標準存取控制器的 audit 與 warn 模式，讓您能輕鬆收集關於 Pod 的重要安全深入分析， 且不會中斷現有的工作負載。

為所有命名空間啟用這些模式是一項良好的做法，將其設定為最終會切換成 enforce 模式的目標層級與版本。 在這個階段產生的警告與審計註解，可以指引您達成此目標狀態。 若您預期工作負載的作者會配合修改以符合目標層級，請啟用 warn 模式。 若您預期透過審計日誌來監控或推動變更以符合目標層級，請啟用 audit 模式。

當您已將 enforce 模式設定至目標層級時，這些模式在以下幾個方面仍能發揮作用：

• 透過將 warn 設定為與 enforce 相同的層級， 當使用者嘗試建立未通過驗證的 Pod（或有 Pod 樣板的資源）時，將會收到警告。 這能協助他們更新這些資源以符合規範。
• 在 enforce 固定於特定非最新版本的命名空間中， 若將 audit 與 warn 模式設定為與 enforce 相同的層級，但版本設為 latest， 可讓您發現那些雖然在舊版本中被允許、但根據目前最佳實務已不再被允許的設定。

第三方替代方案

Kubernetes 生態系中也在開發其他用於強制實施安全設定檔的替代方案：

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

選擇使用內建方案（例如 Pod 安全存取控制器）還是第三方工具，完全視您的實際情況而定。 在評估任何方案時，對供應鏈的信任至關重要。 總之，採用上述任何一種做法，都比完全不做來得更好。