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