免費AI編程助手
W3Cschool
恭喜您成為首批注冊用戶
獲得88經(jīng)驗值獎勵
Kubernetes Pod安全性標(biāo)準(zhǔn)
Pod 安全性標(biāo)準(zhǔn)
Pod 安全性標(biāo)準(zhǔn)定義了三種不同的 策略（Policy），以廣泛覆蓋安全應(yīng)用場景。 這些策略是 漸進式的（Cumulative），安全級別從高度寬松至高度受限。 本指南概述了每個策略的要求。
| Profile | 描述 |
|---|---|
| Privileged | 不受限制的策略，提供最大可能范圍的權(quán)限許可。此策略允許已知的特權(quán)提升。 |
| Baseline | 限制性最弱的策略，禁止已知的策略提升。允許使用默認(rèn)的（規(guī)定最少）Pod 配置。 |
| Restricted | 限制性非常強的策略，遵循當(dāng)前的保護 Pod 的最佳實踐。 |
Profile 細(xì)節(jié)
Privileged
Privileged 策略是有目的地開放且完全無限制的策略。 此類策略通常針對由特權(quán)較高、受信任的用戶所管理的系統(tǒng)級或基礎(chǔ)設(shè)施級負(fù)載。
Privileged 策略定義中限制較少。對于默認(rèn)允許（Allow-by-default）實施機制（例如 gatekeeper）， Privileged 框架可能意味著不應(yīng)用任何約束而不是實施某策略實例。 與此不同，對于默認(rèn)拒絕（Deny-by-default）實施機制（如 Pod 安全策略）而言， Privileged 策略應(yīng)該默認(rèn)允許所有控制（即，禁止所有限制）。
Baseline
Baseline 策略的目標(biāo)是便于常見的容器化應(yīng)用采用，同時禁止已知的特權(quán)提升。 此策略針對的是應(yīng)用運維人員和非關(guān)鍵性應(yīng)用的開發(fā)人員。 下面列舉的控制應(yīng)該被實施（禁止）：
Note:
在下述表格中，通配符（?*?）意味著一個列表中的所有元素。 例如 ?spec.containers[*].securityContext? 表示 所定義的所有容器 的安全性上下文對象。 如果所列出的任一容器不能滿足要求，整個 Pod 將無法通過校驗。
| 控制（Control） | 策略（Policy） |
| HostProcess |
Windows Pod 提供了運行 HostProcess 容器 的能力， 這使得對 Windows 節(jié)點的特權(quán)訪問成為可能。 基線策略中對宿主的特權(quán)訪問是被禁止的。 HostProcess Pod 是 Kubernetes v1.22 版本的 alpha 特性。 限制的字段
允許的值
|
| 宿主名字空間 |
必須禁止共享宿主名字空間。 限制的字段
允許的值
|
| 特權(quán)容器 |
特權(quán) Pod 關(guān)閉了大多數(shù)安全性機制，必須被禁止。 限制的字段
允許的值
|
| 權(quán)能 |
必須禁止添加除下列字段之外的權(quán)能。 限制的字段
允許的值
|
| HostPath 卷 |
必須禁止 HostPath 卷。 限制的字段
允許的值
|
| 宿主端口 |
應(yīng)禁止使用宿主端口，或者至少限定為已知列表。 限制的字段
允許的值
|
| AppArmor |
在受支持的主機上，默認(rèn)使用 限制的字段
允許的值
|
| SELinux |
設(shè)置 SELinux 類型的操作是被限制的，設(shè)置自定義的 SELinux 用戶或角色選項是被禁止的。 限制的字段
允許的值
限制的字段
允許的值
|
/proc 掛載類型 |
要求使用默認(rèn)的 限制的字段
允許的值
|
| Seccomp |
Seccomp Profile 禁止被顯式設(shè)置為 限制的字段
允許的值
|
| Sysctls |
Sysctls 可以禁用安全機制或影響宿主上所有容器，因此除了若干“安全”的子集之外，應(yīng)該被禁止。 如果某 sysctl 是受容器或 Pod 的名字空間限制，且與節(jié)點上其他 Pod 或進程相隔離，可認(rèn)為是安全的。 限制的字段
允許的值
|
Restricted
Restricted 策略旨在實施當(dāng)前保護 Pod 的最佳實踐，盡管這樣作可能會犧牲一些兼容性。 該類策略主要針對運維人員和安全性很重要的應(yīng)用的開發(fā)人員，以及不太被信任的用戶。 下面列舉的控制需要被實施（禁止）：
Note: 在下述表格中，通配符（?
*?）意味著一個列表中的所有元素。 例如 ?spec.containers[*].securityContext? 表示 所定義的所有容器 的安全性上下文對象。 如果所列出的任一容器不能滿足要求，整個 Pod 將無法通過校驗。
| 控制（Control） | 策略（Policy） |
| 基線策略的所有要求。 | |
| 卷類型 |
除了限制 HostPath 卷之外，此類策略還限制可以通過 PersistentVolumes 定義的非核心卷類型。 限制的字段
允許的值 spec.volumes[*] 列表中的每個條目必須將下面字段之一設(shè)置為非空值：
|
| 特權(quán)提升（v1.8+） |
禁止（通過 SetUID 或 SetGID 文件模式）獲得特權(quán)提升。 限制的字段
允許的值
|
| 以非 root 賬號運行 |
必須要求容器以非 root 用戶運行。 限制的字段
允許的值
spec.securityContext.runAsNonRoot 設(shè)置為 true，則允許容器組的安全上下文字段設(shè)置為 未定義/nil。
|
| 非 root 用戶（v1.23+） |
Containers 不可以將 runAsUser 設(shè)置為 0 限制的字段
允許的字段
|
| Seccomp (v1.19+) |
Seccomp Profile 必須被顯式設(shè)置成一個允許的值。禁止使用 限制的字段
允許的值
spec.securityContext.seccompProfile.type 已設(shè)置得當(dāng)，容器級別的安全上下文字段可以為 未定義/nil。 反過來說，如果 _所有的_ 容器級別的安全上下文字段已設(shè)置，則 Pod 級別的字段可為 未定義/nil。
|
| 權(quán)能（v1.22+） |
容器組必須棄用 限制的字段
允許的值
限制的字段
允許的值
|
策略實例化
將策略定義從策略實例中解耦出來有助于形成跨集群的策略理解和語言陳述， 以免綁定到特定的下層實施機制。
隨著相關(guān)機制的成熟，這些機制會按策略分別定義在下面。特定策略的實施方法不在這里定義。
Pod 安全性準(zhǔn)入控制器
PodSecurityPolicy （已棄用）
常見問題
為什么不存在介于 Privileged 和 Baseline 之間的策略類型
這里定義的三種策略框架有一個明晰的線性遞進關(guān)系，從最安全（Restricted）到最不安全， 并且覆蓋了很大范圍的工作負(fù)載。特權(quán)要求超出 Baseline 策略者通常是特定于應(yīng)用的需求， 所以我們沒有在這個范圍內(nèi)提供標(biāo)準(zhǔn)框架。 這并不意味著在這樣的情形下仍然只能使用 Privileged 框架，只是說處于這個范圍的 策略需要因地制宜地定義。
SIG Auth 可能會在將來考慮這個范圍的框架，前提是有對其他框架的需求。
安全策略與安全上下文的區(qū)別是什么？
安全上下文在運行時配置 Pod 和容器。安全上下文是在 Pod 清單中作為 Pod 和容器規(guī)約的一部分來定義的，所代表的是 傳遞給容器運行時的參數(shù)。
安全策略則是控制面用來對安全上下文以及安全性上下文之外的參數(shù)實施某種設(shè)置的機制。 在 2020 年 7 月， Pod 安全性策略已被廢棄， 取而代之的是內(nèi)置的 Pod 安全性準(zhǔn)入控制器。
Kubernetes 生態(tài)系統(tǒng)中還在開發(fā)一些其他的替代方案，例如
我應(yīng)該為我的 Windows Pod 實施哪種框架？
Kubernetes 中的 Windows 負(fù)載與標(biāo)準(zhǔn)的基于 Linux 的負(fù)載相比有一些局限性和區(qū)別。 尤其是 Pod SecurityContext 字段 對 Windows 不起作用。 因此，目前沒有對應(yīng)的標(biāo)準(zhǔn) Pod 安全性框架。
如果你為一個 Windows Pod 應(yīng)用了 Restricted 策略，可能會 對該 Pod 的運行時產(chǎn)生影響。 Restricted 策略需要強制執(zhí)行 Linux 特有的限制（如 seccomp Profile，并且禁止特權(quán)提升）。 如果 kubelet 和/或其容器運行時忽略了 Linux 特有的值，那么應(yīng)該不影響 Windows Pod 正常工作。 然而，對于使用 Windows 容器的 Pod 來說，缺乏強制執(zhí)行意味著相比于 Restricted 策略，沒有任何額外的限制。
你應(yīng)該只在 Privileged 策略下使用 HostProcess 標(biāo)志來創(chuàng)建 HostProcess Pod。 在 Baseline 和 Restricted 策略下，創(chuàng)建 Windows HostProcess Pod 是被禁止的， 因此任何 HostProcess Pod 都應(yīng)該被認(rèn)為是有特權(quán)的。
沙箱（Sandboxed） Pod 怎么處理？
現(xiàn)在還沒有 API 標(biāo)準(zhǔn)來控制 Pod 是否被視作沙箱化 Pod。 沙箱 Pod 可以通過其是否使用沙箱化運行時（如 gVisor 或 Kata Container）來辨別，不過 目前還沒有關(guān)于什么是沙箱化運行時的標(biāo)準(zhǔn)定義。
沙箱化負(fù)載所需要的保護可能彼此各不相同。例如，當(dāng)負(fù)載與下層內(nèi)核直接隔離開來時， 限制特權(quán)化操作的許可就不那么重要。這使得那些需要更多許可權(quán)限的負(fù)載仍能被有效隔離。
此外，沙箱化負(fù)載的保護高度依賴于沙箱化的實現(xiàn)方法。 因此，現(xiàn)在還沒有針對所有沙箱化負(fù)載的建議策略。
- 內(nèi)容錯誤
- 更新不及時
- 鏈接錯誤
- 缺少代碼/圖片示列
- 太簡單/步驟待完善
- 其他
Copyright©2021 w3cschool編程獅|閩ICP備15016281號-3|閩公網(wǎng)安備35020302033924號
違法和不良信息舉報電話：173-0602-2364|舉報郵箱：jubao@eeedong.com
掃描二維碼
下載編程獅App
編程獅公眾號
-
意見反饋：
聯(lián)系方式：
- 廣告等垃圾信息
- 不友善內(nèi)容
- 違反法律法規(guī)的內(nèi)容
- 不宜公開討論的政治內(nèi)容
- 其他
豆包
智譜清言
訊飛星火
更多建議：