Pod 安全性標準
詳細了解 Pod 安全性標準中定義的不同策略層級。
Pod 安全性標準定義了三種不同的策略,以廣泛涵蓋安全性範圍。這些策略是累積的,範圍從高度寬鬆到高度限制。本指南概述了每種策略的要求。
設定檔 | 描述 |
---|
特權 | 不受限制的策略,提供最廣泛的權限層級。此策略允許已知的權限提升。 |
基準 | 最小限制性策略,可防止已知的權限提升。允許預設(最小指定)Pod 組態。 |
受限 | 高度限制性策略,遵循目前的 Pod 強化最佳實務。 |
設定檔詳細資訊
特權
特權策略是刻意開放且完全不受限制的。 此類型的策略通常針對由特權、受信任使用者管理的系統和基礎架構層級工作負載。
特權策略由缺乏限制來定義。如果您定義一個套用特權安全性策略的 Pod,則您定義的 Pod 能夠繞過典型的容器隔離機制。例如,您可以定義一個可以存取節點主機網路的 Pod。
基準
基準策略旨在讓常見的容器化工作負載易於採用,同時防止已知的權限提升。 此策略的目標對象是非關鍵應用程式的應用程式操作員和開發人員。應強制執行/不允許下列列出的控制項
注意
在此表中,萬用字元 (*
) 表示清單中的所有元素。例如,spec.containers[*].securityContext
指的是所有已定義容器的安全性內容物件。如果任何列出的容器未能滿足需求,則整個 Pod 將驗證失敗。基準策略規格控制項 | 策略 |
---|
HostProcess | Windows Pod 提供執行 HostProcess 容器 的能力,這可以實現對 Windows 主機的特權存取。基準策略中不允許對主機的特權存取。 功能狀態: Kubernetes v1.26 [穩定] 受限欄位 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
允許的值 - 未定義/nil
AUDIT_WRITE CHOWN DAC_OVERRIDE FOWNER FSETID KILL MKNOD NET_BIND_SERVICE SETFCAP SETGID SETPCAP SETUID SYS_CHROOT
|
HostPath 磁碟區 | 必須禁止 HostPath 磁碟區。 受限欄位 允許的值 |
主機連接埠 | 應完全不允許 HostPorts(建議),或將其限制為已知清單 受限欄位 spec.containers[*].ports[*].hostPort spec.initContainers[*].ports[*].hostPort spec.ephemeralContainers[*].ports[*].hostPort
允許的值 |
AppArmor | 在支援的主機上,預設會套用 RuntimeDefault AppArmor 設定檔。基準策略應防止覆寫或停用預設 AppArmor 設定檔,或將覆寫限制為允許的設定檔集。 受限欄位 spec.securityContext.appArmorProfile.type spec.containers[*].securityContext.appArmorProfile.type spec.initContainers[*].securityContext.appArmorProfile.type spec.ephemeralContainers[*].securityContext.appArmorProfile.type
允許的值 - 未定義/nil
RuntimeDefault Localhost
metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]
允許的值 - 未定義/nil
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
允許的值 - 未定義/nil
RuntimeDefault Localhost
|
Sysctl | Sysctl 可以禁用安全機制或影響主機上的所有容器,除非是允許的「安全」子集,否則應被禁止。如果 sysctl 在容器或 Pod 中被命名空間化,並且與同一節點上的其他 Pod 或進程隔離,則該 sysctl 被認為是安全的。 受限欄位 spec.securityContext.sysctls[*].name
允許的值 - 未定義/nil
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 起)
|
受限
Restricted 原則旨在強制執行當前 Pod 強化的最佳實務,但會犧牲一些相容性。 它適用於安全至關重要的應用程式的運營商和開發人員,以及較低信任的使用者。以下列出的控制項應被強制執行/禁止
注意
在此表中,萬用字元 (*
) 表示清單中的所有元素。例如,spec.containers[*].securityContext
指的是所有已定義容器的安全性內容物件。如果任何列出的容器未能滿足需求,則整個 Pod 將驗證失敗。Restricted 原則規範控制項 | 策略 |
Baseline 原則中的所有內容 |
Volume 類型 | Restricted 原則僅允許以下 volume 類型。 受限欄位 允許的值 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 。 |
功能 (Capabilities) (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 之前的 Kubelet 不會強制執行 Pod OS 欄位,如果叢集中的節點版本早於 v1.24,則 Restricted 原則應釘選到早於 v1.25 的版本。Restricted Pod 安全標準變更
Kubernetes v1.25 中進行的另一個重要變更是,Restricted 原則已更新為使用 pod.spec.os.name
欄位。根據 OS 名稱,可以為其他 OS 放寬特定於特定 OS 的某些原則。
特定於 OS 的原則控制項
只有在 .spec.os.name
不是 windows
時,才需要限制以下控制項
使用者命名空間
使用者命名空間是一項僅限 Linux 的功能,用於以更高的隔離性執行工作負載。它們如何與 Pod 安全標準協同工作在針對使用使用者命名空間的 Pod 的文件中進行了描述。
常見問題
為什麼在 Privileged 和 Baseline 之間沒有配置檔?
此處定義的三個配置檔具有從最安全 (Restricted) 到最不安全 (Privileged) 的清晰線性進程,並涵蓋了廣泛的工作負載。高於 Baseline 原則所需的權限通常非常特定於應用程式,因此我們在此領域不提供標準配置檔。這並不是說在這種情況下應始終使用 privileged 配置檔,而是說此空間中的原則需要根據具體情況定義。
如果未來出現對其他配置檔的明確需求,SIG Auth 可能會重新考慮此立場。
安全配置檔和安全上下文之間有什麼區別?
安全上下文在執行時配置 Pod 和容器。安全上下文定義為 Pod 資訊清單中 Pod 和容器規範的一部分,並表示容器執行時的參數。
安全配置檔是控制平面機制,用於強制執行安全上下文中的特定設定,以及安全上下文之外的其他相關參數。截至 2021 年 7 月,Pod 安全策略已被棄用,取而代之的是內建的 Pod 安全准入控制器。
沙箱化 Pod 呢?
目前沒有 API 標準來控制 Pod 是否被視為沙箱化。沙箱 Pod 可以透過使用沙箱化執行時(例如 gVisor 或 Kata Containers)來識別,但沙箱化執行時沒有標準定義。
沙箱化工作負載所需的保護可能與其他工作負載不同。例如,當工作負載與底層核心隔離時,限制特權權限的需求會降低。這允許需要更高權限的工作負載仍然被隔離。
此外,沙箱化工作負載的保護高度依賴於沙箱化的方法。因此,沒有針對所有沙箱化工作負載的單一建議配置檔。
此頁面上的項目引用了提供 Kubernetes 所需功能的協力廠商產品或專案。Kubernetes 專案作者不對這些協力廠商產品或專案負責。有關更多詳細資訊,請參閱 CNCF 網站指南。
在提出新增額外協力廠商連結的變更之前,您應該閱讀內容指南。