強制執行 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.

選擇使用內建解決方案 (例如 PodSecurity 許可控制器) 還是第三方工具完全取決於您自身的情況。在評估任何解決方案時，對供應鏈的信任至關重要。最終，使用任何上述方法都會比什麼都不做要好。