建站
咨詢
售后
建站咨詢
新聞中心
Pod 安全性標(biāo)準(zhǔn)
Pod 安全性標(biāo)準(zhǔn)定義了三種不同的 策略（Policy），以廣泛覆蓋安全應(yīng)用場(chǎng)景。 這些策略是 漸進(jìn)式的（Cumulative），安全級(jí)別從高度寬松至高度受限。 本指南概述了每個(gè)策略的要求。
| Profile | 描述 |
|---|---|
| Privileged | 不受限制的策略，提供最大可能范圍的權(quán)限許可。此策略允許已知的特權(quán)提升。 |
| Baseline | 限制性最弱的策略，禁止已知的策略提升。允許使用默認(rèn)的（規(guī)定最少）Pod 配置。 |
| Restricted | 限制性非常強(qiáng)的策略，遵循當(dāng)前的保護(hù) Pod 的最佳實(shí)踐。 |
Profile 細(xì)節(jié)
Privileged
Privileged 策略是有目的地開放且完全無限制的策略。 此類策略通常針對(duì)由特權(quán)較高、受信任的用戶所管理的系統(tǒng)級(jí)或基礎(chǔ)設(shè)施級(jí)負(fù)載。
Privileged 策略定義中限制較少。對(duì)于默認(rèn)允許（Allow-by-default）實(shí)施機(jī)制（例如 gatekeeper）， Privileged 框架可能意味著不應(yīng)用任何約束而不是實(shí)施某策略實(shí)例。 與此不同，對(duì)于默認(rèn)拒絕（Deny-by-default）實(shí)施機(jī)制（如 Pod 安全策略）而言， Privileged 策略應(yīng)該默認(rèn)允許所有控制（即，禁止所有限制）。
Baseline
Baseline 策略的目標(biāo)是便于常見的容器化應(yīng)用采用，同時(shí)禁止已知的特權(quán)提升。 此策略針對(duì)的是應(yīng)用運(yùn)維人員和非關(guān)鍵性應(yīng)用的開發(fā)人員。 下面列舉的控制應(yīng)該被實(shí)施（禁止）：
Note:
在下述表格中，通配符（?
*?）意味著一個(gè)列表中的所有元素。 例如 ?
spec.containers[*].securityContext? 表示 所定義的所有容器 的安全性上下文對(duì)象。 如果所列出的任一容器不能滿足要求，整個(gè) Pod 將無法通過校驗(yàn)。
| 控制（Control） | 策略（Policy） |
| HostProcess | Windows Pod 提供了運(yùn)行 HostProcess 容器 的能力， 這使得對(duì) Windows 節(jié)點(diǎn)的特權(quán)訪問成為可能。 基線策略中對(duì)宿主的特權(quán)訪問是被禁止的。 HostProcess Pod 是 Kubernetes v1.22 版本的 alpha 特性。 限制的字段
允許的值
|
| 宿主名字空間 | 必須禁止共享宿主名字空間。 限制的字段
允許的值
|
| 特權(quán)容器 | 特權(quán) Pod 關(guān)閉了大多數(shù)安全性機(jī)制，必須被禁止。 限制的字段
允許的值
|
| 權(quán)能 | 必須禁止添加除下列字段之外的權(quán)能。 限制的字段
允許的值
|
| HostPath 卷 | 必須禁止 HostPath 卷。 限制的字段
允許的值
|
| 宿主端口 | 應(yīng)禁止使用宿主端口，或者至少限定為已知列表。 限制的字段
允許的值
|
| AppArmor | 在受支持的主機(jī)上，默認(rèn)使用 限制的字段
允許的值
|
| SELinux | 設(shè)置 SELinux 類型的操作是被限制的，設(shè)置自定義的 SELinux 用戶或角色選項(xiàng)是被禁止的。 限制的字段
允許的值
限制的字段
允許的值
|
/proc 掛載類型 |
要求使用默認(rèn)的 限制的字段
允許的值
|
| Seccomp | Seccomp Profile 禁止被顯式設(shè)置為 限制的字段
允許的值
|
| Sysctls | Sysctls 可以禁用安全機(jī)制或影響宿主上所有容器，因此除了若干“安全”的子集之外，應(yīng)該被禁止。 如果某 sysctl 是受容器或 Pod 的名字空間限制，且與節(jié)點(diǎn)上其他 Pod 或進(jìn)程相隔離，可認(rèn)為是安全的。 限制的字段
允許的值
|
Restricted
Restricted 策略旨在實(shí)施當(dāng)前保護(hù) Pod 的最佳實(shí)踐，盡管這樣作可能會(huì)犧牲一些兼容性。 該類策略主要針對(duì)運(yùn)維人員和安全性很重要的應(yīng)用的開發(fā)人員，以及不太被信任的用戶。 下面列舉的控制需要被實(shí)施（禁止）：
Note: 在下述表格中，通配符（?
*?）意味著一個(gè)列表中的所有元素。 例如 ?spec.containers[*].securityContext? 表示 所定義的所有容器 的安全性上下文對(duì)象。 如果所列出的任一容器不能滿足要求，整個(gè) Pod 將無法通過校驗(yàn)。
| 控制（Control） | 策略（Policy） |
| 基線策略的所有要求。 | |
| 卷類型 | 除了限制 HostPath 卷之外，此類策略還限制可以通過 PersistentVolumes 定義的非核心卷類型。 限制的字段
允許的值
|
| 特權(quán)提升（v1.8+） | 禁止（通過 SetUID 或 SetGID 文件模式）獲得特權(quán)提升。 限制的字段
允許的值
|
| 以非 root 賬號(hào)運(yùn)行 | 必須要求容器以非 root 用戶運(yùn)行。 限制的字段
允許的值
如果 Pod 級(jí)別 |
| 非 root 用戶（v1.23+） | Containers 不可以將 runAsUser 設(shè)置為 0 限制的字段
允許的字段
|
| Seccomp (v1.19+) | Seccomp Profile 必須被顯式設(shè)置成一個(gè)允許的值。禁止使用 限制的字段
允許的值
如果 Pod 級(jí)別的 |
| 權(quán)能（v1.22+） | 容器組必須棄用 限制的字段
允許的值
限制的字段
允許的值
|
策略實(shí)例化
將策略定義從策略實(shí)例中解耦出來有助于形成跨集群的策略理解和語言陳述， 以免綁定到特定的下層實(shí)施機(jī)制。
隨著相關(guān)機(jī)制的成熟，這些機(jī)制會(huì)按策略分別定義在下面。特定策略的實(shí)施方法不在這里定義。
Pod 安全性準(zhǔn)入控制器
- Privileged 名字空間
- Baseline 名字空間
- Restricted 名字空間
PodSecurityPolicy （已棄用）
- Privileged
- Baseline
- Restricted
常見問題
為什么不存在介于 Privileged 和 Baseline 之間的策略類型
這里定義的三種策略框架有一個(gè)明晰的線性遞進(jìn)關(guān)系，從最安全（Restricted）到最不安全， 并且覆蓋了很大范圍的工作負(fù)載。特權(quán)要求超出 Baseline 策略者通常是特定于應(yīng)用的需求， 所以我們沒有在這個(gè)范圍內(nèi)提供標(biāo)準(zhǔn)框架。 這并不意味著在這樣的情形下仍然只能使用 Privileged 框架，只是說處于這個(gè)范圍的 策略需要因地制宜地定義。
SIG Auth 可能會(huì)在將來考慮這個(gè)范圍的框架，前提是有對(duì)其他框架的需求。
安全策略與安全上下文的區(qū)別是什么？
安全上下文在運(yùn)行時(shí)配置 Pod 和容器。安全上下文是在 Pod 清單中作為 Pod 和容器規(guī)約的一部分來定義的，所代表的是 傳遞給容器運(yùn)行時(shí)的參數(shù)。
安全策略則是控制面用來對(duì)安全上下文以及安全性上下文之外的參數(shù)實(shí)施某種設(shè)置的機(jī)制。 在 2020 年 7 月， Pod 安全性策略已被廢棄， 取而代之的是內(nèi)置的 Pod 安全性準(zhǔn)入控制器。
Kubernetes 生態(tài)系統(tǒng)中還在開發(fā)一些其他的替代方案，例如
- OPA Gatekeeper
- Kubewarden
- Kyverno
我應(yīng)該為我的 Windows Pod 實(shí)施哪種框架？
Kubernetes 中的 Windows 負(fù)載與標(biāo)準(zhǔn)的基于 Linux 的負(fù)載相比有一些局限性和區(qū)別。 尤其是 Pod SecurityContext 字段 對(duì) Windows 不起作用。 因此，目前沒有對(duì)應(yīng)的標(biāo)準(zhǔn) Pod 安全性框架。
如果你為一個(gè) Windows Pod 應(yīng)用了 Restricted 策略，可能會(huì) 對(duì)該 Pod 的運(yùn)行時(shí)產(chǎn)生影響。 Restricted 策略需要強(qiáng)制執(zhí)行 Linux 特有的限制（如 seccomp Profile，并且禁止特權(quán)提升）。 如果 kubelet 和/或其容器運(yùn)行時(shí)忽略了 Linux 特有的值，那么應(yīng)該不影響 Windows Pod 正常工作。 然而，對(duì)于使用 Windows 容器的 Pod 來說，缺乏強(qiáng)制執(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 可以通過其是否使用沙箱化運(yùn)行時(shí)（如 gVisor 或 Kata Container）來辨別，不過 目前還沒有關(guān)于什么是沙箱化運(yùn)行時(shí)的標(biāo)準(zhǔn)定義。
沙箱化負(fù)載所需要的保護(hù)可能彼此各不相同。例如，當(dāng)負(fù)載與下層內(nèi)核直接隔離開來時(shí)， 限制特權(quán)化操作的許可就不那么重要。這使得那些需要更多許可權(quán)限的負(fù)載仍能被有效隔離。
此外，沙箱化負(fù)載的保護(hù)高度依賴于沙箱化的實(shí)現(xiàn)方法。 因此，現(xiàn)在還沒有針對(duì)所有沙箱化負(fù)載的建議策略。
標(biāo)題名稱：創(chuàng)新互聯(lián)kubernetes教程：KubernetesPod安全性標(biāo)準(zhǔn)
網(wǎng)頁地址：http://fisionsoft.com.cn/article/cdhdseg.html
