Pod 安全標準
詳細瞭解 Pod 安全標準中定義的各種策略級別。
Pod 安全標準定義了三種不同的**策略**,以廣泛覆蓋安全範圍。這些策略是**累積的**,範圍從高度寬鬆到高度限制。本指南概述了每項策略的要求。
配置檔案 | 描述 |
---|
特權 | 不受限制的策略,提供最廣泛的許可權級別。此策略允許已知的許可權提升。 |
基線 | 限制最少的策略,可防止已知的許可權提升。允許預設(最低限度指定)Pod 配置。 |
受限 | 嚴格受限的策略,遵循當前的 Pod 強化最佳實踐。 |
配置檔案詳情
特權
**“特權”策略是刻意開放的,並且完全不受限制。** 此類策略通常針對由特權、受信任使用者管理的系統和基礎設施級別工作負載。
特權策略的定義是沒有限制。如果定義 Pod 時應用了特權安全策略,那麼所定義的 Pod 能夠繞過典型的容器隔離機制。例如,你可以定義一個可以訪問節點主機網路的 Pod。
基線
**基線策略旨在方便常見的容器化工作負載的採用,同時防止已知的許可權提升。** 此策略面向非關鍵應用程式的應用程式操作員和開發人員。應強制執行/禁止以下列出的控制:
注意
在此表中,萬用字元 (*
) 表示列表中的所有元素。例如,spec.containers[*].securityContext
指的是**所有已定義容器**的 Security Context 物件。如果任何列出的容器未能滿足要求,整個 Pod 將無法透過驗證。基線策略規範控制 | 策略 |
---|
主機程序 | Windows Pod 提供了執行 HostProcess 容器 的能力,從而可以對 Windows 主機進行特權訪問。基線策略禁止對主機的特權訪問。 功能狀態: Kubernetes v1.26 [stable] 受限欄位 spec.securityContext.windowsOptions.hostProcess spec.containers[*].securityContext.windowsOptions.hostProcess spec.initContainers[*].securityContext.windowsOptions.hostProcess spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess
允許值 |
主機名稱空間 | 必須禁止共享主機名稱空間。 受限欄位 spec.hostNetwork spec.hostPID spec.hostIPC
允許值 |
特權容器 | 特權 Pod 停用大多數安全機制,必須予以禁止。 受限欄位 spec.containers[*].securityContext.privileged spec.initContainers[*].securityContext.privileged spec.ephemeralContainers[*].securityContext.privileged
允許值 |
能力 | 必須禁止新增除以下列出的能力之外的額外能力。 受限欄位 spec.containers[*].securityContext.capabilities.add spec.initContainers[*].securityContext.capabilities.add spec.ephemeralContainers[*].securityContext.capabilities.add
允許值 - 未定義/空
AUDIT_WRITE CHOWN DAC_OVERRIDE FOWNER FSETID KILL MKNOD NET_BIND_SERVICE SETFCAP SETGID SETPCAP SETUID SYS_CHROOT
|
HostPath 卷 | 必須禁止 HostPath 卷。 受限欄位 允許值 |
主機埠 | 主機埠應完全停用(推薦)或限制為已知列表。 受限欄位 spec.containers[*].ports[*].hostPort spec.initContainers[*].ports[*].hostPort spec.ephemeralContainers[*].ports[*].hostPort
允許值 |
主機探測 / 生命週期鉤子 (v1.34+) | 必須禁止探測和生命週期鉤子中的 Host 欄位。 受限欄位 spec.containers[*].livenessProbe.httpGet.host spec.containers[*].readinessProbe.httpGet.host spec.containers[*].startupProbe.httpGet.host spec.containers[*].livenessProbe.tcpSocket.host spec.containers[*].readinessProbe.tcpSocket.host spec.containers[*].startupProbe.tcpSocket.host spec.containers[*].lifecycle.postStart.tcpSocket.host spec.containers[*].lifecycle.preStop.tcpSocket.host spec.containers[*].lifecycle.postStart.httpGet.host spec.containers[*].lifecycle.preStop.httpGet.host spec.initContainers[*].livenessProbe.httpGet.host spec.initContainers[*].readinessProbe.httpGet.host spec.initContainers[*].startupProbe.httpGet.host spec.initContainers[*].livenessProbe.tcpSocket.host spec.initContainers[*].readinessProbe.tcpSocket.host spec.initContainers[*].startupProbe.tcpSocket.host spec.initContainers[*].lifecycle.postStart.tcpSocket.host spec.initContainers[*].lifecycle.preStop.tcpSocket.host spec.initContainers[*].lifecycle.postStart.httpGet.host spec.initContainers[*].lifecycle.preStop.httpGet.host
允許值 |
AppArmor | 在支援的主機上,預設應用 `RuntimeDefault` AppArmor 配置檔案。基線策略應阻止覆蓋或停用預設 AppArmor 配置檔案,或將覆蓋限制為一組允許的配置檔案。 受限欄位 spec.securityContext.appArmorProfile.type spec.containers[*].securityContext.appArmorProfile.type spec.initContainers[*].securityContext.appArmorProfile.type spec.ephemeralContainers[*].securityContext.appArmorProfile.type
允許值 - 未定義/空
RuntimeDefault Localhost
metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]
允許值 - 未定義/空
runtime/default localhost/*
|
SELinux | SELinux 型別的設定受到限制,並且禁止設定自定義 SELinux 使用者或角色選項。 受限欄位 spec.securityContext.seLinuxOptions.type spec.containers[*].securityContext.seLinuxOptions.type spec.initContainers[*].securityContext.seLinuxOptions.type spec.ephemeralContainers[*].securityContext.seLinuxOptions.type
允許值 - 未定義/""
container_t container_init_t container_kvm_t container_engine_t (自 Kubernetes 1.31 起)
受限欄位 spec.securityContext.seLinuxOptions.user spec.containers[*].securityContext.seLinuxOptions.user spec.initContainers[*].securityContext.seLinuxOptions.user spec.ephemeralContainers[*].securityContext.seLinuxOptions.user spec.securityContext.seLinuxOptions.role spec.containers[*].securityContext.seLinuxOptions.role spec.initContainers[*].securityContext.seLinuxOptions.role spec.ephemeralContainers[*].securityContext.seLinuxOptions.role
允許值 |
/proc 掛載型別 | 預設的 /proc 掩碼旨在減少攻擊面,應作為強制要求。 受限欄位 spec.containers[*].securityContext.procMount spec.initContainers[*].securityContext.procMount spec.ephemeralContainers[*].securityContext.procMount
允許值 |
Seccomp | Seccomp 配置檔案不得明確設定為 Unconfined 。 受限欄位 spec.securityContext.seccompProfile.type spec.containers[*].securityContext.seccompProfile.type spec.initContainers[*].securityContext.seccompProfile.type spec.ephemeralContainers[*].securityContext.seccompProfile.type
允許值 - 未定義/空
RuntimeDefault Localhost
|
Sysctls | Sysctls 可以停用安全機制或影響主機上的所有容器,因此除了允許的“安全”子集外,應予以禁止。如果 sysctl 在容器或 Pod 中名稱空間隔離,並且與同一節點上的其他 Pod 或程序隔離,則視為安全。 受限欄位 spec.securityContext.sysctls[*].name
允許值 - 未定義/空
kernel.shm_rmid_forced net.ipv4.ip_local_port_range net.ipv4.ip_unprivileged_port_start net.ipv4.tcp_syncookies net.ipv4.ping_group_range net.ipv4.ip_local_reserved_ports (自 Kubernetes 1.27 起)net.ipv4.tcp_keepalive_time (自 Kubernetes 1.29 起)net.ipv4.tcp_fin_timeout (自 Kubernetes 1.29 起)net.ipv4.tcp_keepalive_intvl (自 Kubernetes 1.29 起)net.ipv4.tcp_keepalive_probes (自 Kubernetes 1.29 起)
|
受限
**受限策略旨在以犧牲一些相容性為代價,強制執行當前的 Pod 強化最佳實踐。** 它針對安全關鍵應用程式的運營商和開發人員,以及較低信任度的使用者。應強制執行/禁止以下列出的控制:
注意
在此表中,萬用字元 (*
) 表示列表中的所有元素。例如,spec.containers[*].securityContext
指的是**所有已定義容器**的 Security Context 物件。如果任何列出的容器未能滿足要求,整個 Pod 將無法透過驗證。受限策略規範控制 | 策略 |
基線策略的所有內容 |
卷型別 | 受限策略只允許以下卷型別。 受限欄位 允許值 spec.volumes[*] 列表中的每個項都必須將以下欄位之一設定為非空值。spec.volumes[*].configMap spec.volumes[*].csi spec.volumes[*].downwardAPI spec.volumes[*].emptyDir spec.volumes[*].ephemeral spec.volumes[*].persistentVolumeClaim spec.volumes[*].projected spec.volumes[*].secret
|
許可權提升 (v1.8+) | 不應允許許可權提升(例如透過 set-user-ID 或 set-group-ID 檔案模式)。這是 v1.25+ 中的 Linux 專用策略 (spec.os.name != windows) 受限欄位 spec.containers[*].securityContext.allowPrivilegeEscalation spec.initContainers[*].securityContext.allowPrivilegeEscalation spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation
允許值 |
以非 root 使用者身份執行 | 容器必須被要求以非 root 使用者身份執行。 受限欄位 spec.securityContext.runAsNonRoot spec.containers[*].securityContext.runAsNonRoot spec.initContainers[*].securityContext.runAsNonRoot spec.ephemeralContainers[*].securityContext.runAsNonRoot
允許值 如果 Pod 級別的 spec.securityContext.runAsNonRoot 設定為 true ,則容器欄位可以未定義/nil 。 |
以非 root 使用者身份執行 (v1.23+) | 容器不得設定runAsUser為 0 受限欄位 spec.securityContext.runAsUser spec.containers[*].securityContext.runAsUser spec.initContainers[*].securityContext.runAsUser spec.ephemeralContainers[*].securityContext.runAsUser
允許值 |
Seccomp (v1.19+) | Seccomp 配置檔案必須明確設定為其中一個允許值。禁止使用 Unconfined 配置檔案和**缺少**配置檔案。*這是 v1.25+ 中的 Linux 專用策略 (spec.os.name != windows) * 受限欄位 spec.securityContext.seccompProfile.type spec.containers[*].securityContext.seccompProfile.type spec.initContainers[*].securityContext.seccompProfile.type spec.ephemeralContainers[*].securityContext.seccompProfile.type
允許值 如果 Pod 級別的 spec.securityContext.seccompProfile.type 欄位已正確設定,則容器欄位可以未定義/nil 。反之,如果**所有**容器級別的欄位都已設定,則 Pod 級別的欄位可以未定義/nil 。 |
能力 (v1.22+) | 容器必須丟棄 ALL 能力,並且只允許重新新增 NET_BIND_SERVICE 能力。*這是 v1.25+ 中的 Linux 專用策略 (.spec.os.name != "windows") * 受限欄位 spec.containers[*].securityContext.capabilities.drop spec.initContainers[*].securityContext.capabilities.drop spec.ephemeralContainers[*].securityContext.capabilities.drop
允許值
受限欄位 spec.containers[*].securityContext.capabilities.add spec.initContainers[*].securityContext.capabilities.add spec.ephemeralContainers[*].securityContext.capabilities.add
允許值 |
策略例項化
將策略定義與策略例項化分離,有助於跨叢集對策略形成共同理解和一致的語言,而與底層強制機制無關。
隨著機制的成熟,它們將根據策略在下面定義。此處未定義單個策略的強制方法。
Pod 安全准入控制器
替代方案
**注意:** 本節連結到提供 Kubernetes 所需功能的第三方專案。Kubernetes 專案作者不對這些按字母順序列出的專案負責。要將專案新增到此列表,請在提交更改之前閱讀
內容指南。
更多資訊。Kubernetes 生態系統中正在開發其他用於強制執行策略的替代方案,例如
Pod OS 欄位
Kubernetes 允許你使用執行 Linux 或 Windows 的節點。你可以在一個叢集中混合使用這兩種節點。Kubernetes 中的 Windows 在某些方面存在侷限性,並與基於 Linux 的工作負載有所不同。具體而言,許多 Pod 的 securityContext
欄位 對 Windows 無效。
注意
v1.24 之前的 Kubelets 不會強制執行 Pod OS 欄位,如果叢集中的節點版本早於 v1.24,受限策略應固定在 v1.25 之前的版本。受限的 Pod 安全標準更改
Kubernetes v1.25 中的另一個重要變化是,**受限**策略已更新,以使用 pod.spec.os.name
欄位。根據 OS 名稱,可以為其他 OS 放寬某些特定於特定 OS 的策略。
作業系統特定策略控制
以下控制的限制僅在 .spec.os.name
不是 windows
時才需要:
使用者名稱空間
使用者名稱空間是 Linux 專有的功能,用於以更高的隔離度執行工作負載。它們與 Pod 安全標準如何協同工作在使用使用者名稱空間的 Pod 文件中有所描述。
常見問題
為什麼在特權和基線之間沒有配置檔案?
此處定義的三種配置檔案具有從最安全(受限)到最不安全(特權)的清晰線性演進,並涵蓋了廣泛的工作負載。高於基線策略所需的特權通常非常特定於應用程式,因此我們不在此領域提供標準配置檔案。這並不是說在這種情況下應始終使用特權配置檔案,而是說該領域中的策略需要根據具體情況進行定義。
如果未來出現對其他配置檔案的明確需求,SIG Auth 可能會重新考慮此立場。
安全配置檔案和安全上下文有什麼區別?
安全上下文在執行時配置 Pod 和容器。安全上下文在 Pod 清單中作為 Pod 和容器規範的一部分進行定義,表示容器執行時的引數。
安全配置檔案是控制平面機制,用於強制執行安全上下文中的特定設定,以及安全上下文之外的其他相關引數。截至 2021 年 7 月,Pod 安全策略已棄用,取而代之的是內建的 Pod 安全准入控制器。
沙盒 Pod 怎麼樣?
目前還沒有一個 API 標準來控制 Pod 是否被認為是沙盒的。沙盒 Pod 可以透過使用沙盒執行時(例如 gVisor 或 Kata Containers)來識別,但沒有沙盒執行時的標準定義。
沙盒工作負載所需的保護措施可能與其他工作負載不同。例如,當工作負載與底層核心隔離時,限制特權許可權的需求就會降低。這使得需要更高許可權的工作負載仍然可以被隔離。
此外,沙盒工作負載的保護高度依賴於沙盒方法。因此,沒有單一的推薦配置檔案適用於所有沙盒工作負載。
本頁上的專案是指提供 Kubernetes 所需功能的第三方產品或專案。Kubernetes 專案作者不對這些第三方產品或專案負責。有關更多詳細資訊,請參閱 CNCF 網站指南。
在提議新增額外第三方連結的更改之前,你應該閱讀內容指南。