強制執行 Pod 安全標準

本頁面概述了強制實施 Pod 安全標準的最佳實踐。

使用內建的 Pod 安全准入控制器

Pod 安全准入控制器旨在取代已廢棄的 PodSecurityPolicy。

配置所有叢集名稱空間

缺乏任何配置的名稱空間應被視為叢集安全模型中的重大漏洞。我們建議花時間分析每個名稱空間中工作負載的型別，並參考 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 准入控制器）還是第三方工具完全取決於你自己的情況。在評估任何解決方案時，供應鏈的信任至關重要。最終，使用上述任何一種方法都比無所作為要好。