新聞中心
使用內(nèi)置的 Pod 安全性準(zhǔn)入控制器
FEATURE STATE: Kubernetes v1.23 [beta]

成都創(chuàng)新互聯(lián)主要從事網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)克井,十年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792
Pod 安全性準(zhǔn)入控制器 嘗試替換已被廢棄的 PodSecurityPolicies。
配置所有集群名字空間
完全未經(jīng)配置的名字空間應(yīng)該被視為集群安全模型中的重大缺陷。 我們建議花一些時間來分析在每個名字空間中執(zhí)行的負(fù)載的類型, 并通過引用 Pod 安全性標(biāo)準(zhǔn)來確定每個負(fù)載的合適級別。 未設(shè)置標(biāo)簽的名字空間應(yīng)該視為尚未被評估。
針對所有名字空間中的所有負(fù)載都具有相同的安全性需求的場景, 我們提供了一個示例 用來展示如何批量應(yīng)用 Pod 安全性標(biāo)簽。
擁抱最小特權(quán)原則
在一個理想環(huán)境中,每個名字空間中的每個 Pod 都會滿足 ?restricted ?策略的需求。 不過,這既不可能也不現(xiàn)實,某些負(fù)載會因為合理的原因而需要特權(quán)上的提升。
- 允許 ?
privileged?負(fù)載的名字空間需要建立并實施適當(dāng)?shù)脑L問控制機制。 - 對于運行在特權(quán)寬松的名字空間中的負(fù)載,需要維護其獨特安全性需求的文檔。 如果可能的話,要考慮如何進一步約束這些需求。
采用多種模式的策略
Pod 安全性標(biāo)準(zhǔn)準(zhǔn)入控制器的 ?audit ?和 ?warn ?模式(mode) 能夠在不影響現(xiàn)有負(fù)載的前提下,讓該控制器更方便地收集關(guān)于 Pod 的重要的安全信息。
針對所有名字空間啟用這些模式是一種好的實踐,將它們設(shè)置為你最終打算 ?enforce ?的 期望的 級別和版本。這一階段中所生成的警告和審計注解信息可以幫助你到達(dá)這一狀態(tài)。 如果你期望負(fù)載的作者能夠作出變更以便適應(yīng)期望的級別,可以啟用 ?warn ?模式。 如果你希望使用審計日志了監(jiān)控和驅(qū)動變更,以便負(fù)載能夠適應(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)重要的。 最終,使用前述方案中的 任何 一種都好過放任自流。
文章題目:創(chuàng)新互聯(lián)kubernetes教程:Kubernetes強制實施Pod安全性標(biāo)準(zhǔn)
本文URL:http://m.fisionsoft.com.cn/article/djssose.html


咨詢
建站咨詢
