Kubernetes 強制實施Pod安全性標(biāo)準(zhǔn)

使用內(nèi)置的 Pod 安全性準(zhǔn)入控制器 

FEATURE STATE: Kubernetes v1.23 [beta]

Pod 安全性準(zhǔn)入控制器 嘗試替換已被廢棄的 PodSecurityPolicies。

配置所有集群名字空間 

完全未經(jīng)配置的名字空間應(yīng)該被視為集群安全模型中的重大缺陷。 我們建議花一些時間來分析在每個名字空間中執(zhí)行的負載的類型， 并通過引用 Pod 安全性標(biāo)準(zhǔn)來確定每個負載的合適級別。 未設(shè)置標(biāo)簽的名字空間應(yīng)該視為尚未被評估。

針對所有名字空間中的所有負載都具有相同的安全性需求的場景， 我們提供了一個示例 用來展示如何批量應(yīng)用 Pod 安全性標(biāo)簽。

擁抱最小特權(quán)原則

在一個理想環(huán)境中，每個名字空間中的每個 Pod 都會滿足 ?restricted ?策略的需求。 不過，這既不可能也不現(xiàn)實，某些負載會因為合理的原因而需要特權(quán)上的提升。

• 允許 ?privileged ?負載的名字空間需要建立并實施適當(dāng)?shù)脑L問控制機制。
• 對于運行在特權(quán)寬松的名字空間中的負載，需要維護其獨特安全性需求的文檔。 如果可能的話，要考慮如何進一步約束這些需求。

采用多種模式的策略

Pod 安全性標(biāo)準(zhǔn)準(zhǔn)入控制器的 ?audit ?和 ?warn ?模式（mode） 能夠在不影響現(xiàn)有負載的前提下，讓該控制器更方便地收集關(guān)于 Pod 的重要的安全信息。

針對所有名字空間啟用這些模式是一種好的實踐，將它們設(shè)置為你最終打算 ?enforce ?的 期望的 級別和版本。這一階段中所生成的警告和審計注解信息可以幫助你到達這一狀態(tài)。 如果你期望負載的作者能夠作出變更以便適應(yīng)期望的級別，可以啟用 ?warn ?模式。 如果你希望使用審計日志了監(jiān)控和驅(qū)動變更，以便負載能夠適應(yīng)期望的級別，可以啟用 ?audit ?模式。

當(dāng)你將 ?enforce ?模式設(shè)置為期望的取值時，這些模式在不同的場合下仍然是有用的：

• 通過將 ?warn ?設(shè)置為 ?enforce ?相同的級別，客戶可以在嘗試創(chuàng)建無法通過合法檢查的 Pod （或者包含 Pod 模板的資源）時收到警告信息。這些信息會幫助于更新資源使其合規(guī)。
• 在將 ?enforce ?鎖定到特定的非最新版本的名字空間中，將 ?audit ?和 ?warn ?模式設(shè)置為 ?enforce ?一樣的級別而非 ?latest ?版本， 這樣可以方便看到之前版本所允許但當(dāng)前最佳實踐中被禁止的設(shè)置。

第三方替代方案

Kubernetes 生態(tài)系統(tǒng)中也有一些其他強制實施安全設(shè)置的替代方案處于開發(fā)狀態(tài)中：

• Kubewarden
• Kyverno
• OPA Gatekeeper

采用 內(nèi)置的 方案（例如 PodSecurity 準(zhǔn)入控制器）還是第三方工具， 這一決策完全取決于你自己的情況。在評估任何解決方案時，對供應(yīng)鏈的信任都是至關(guān)重要的。 最終，使用前述方案中的 任何 一種都好過放任自流。