Pod 安全性標準

詳細了解 Pod 安全性標準中定義的不同策略層級。

Pod 安全性標準定義了三種不同的策略,以廣泛涵蓋安全性範圍。這些策略是累積的,範圍從高度寬鬆到高度限制。本指南概述了每種策略的要求。

設定檔描述
特權不受限制的策略,提供最廣泛的權限層級。此策略允許已知的權限提升。
基準最小限制性策略,可防止已知的權限提升。允許預設(最小指定)Pod 組態。
受限高度限制性策略,遵循目前的 Pod 強化最佳實務。

設定檔詳細資訊

特權

特權策略是刻意開放且完全不受限制的。 此類型的策略通常針對由特權、受信任使用者管理的系統和基礎架構層級工作負載。

特權策略由缺乏限制來定義。如果您定義一個套用特權安全性策略的 Pod,則您定義的 Pod 能夠繞過典型的容器隔離機制。例如,您可以定義一個可以存取節點主機網路的 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

允許的值

  • 未定義/nil
  • false
主機命名空間

必須不允許共用主機命名空間。

受限欄位

  • spec.hostNetwork
  • spec.hostPID
  • spec.hostIPC

允許的值

  • 未定義/nil
  • false
特權容器

特權 Pod 會停用大多數安全性機制,因此必須不允許。

受限欄位

  • spec.containers[*].securityContext.privileged
  • spec.initContainers[*].securityContext.privileged
  • spec.ephemeralContainers[*].securityContext.privileged

允許的值

  • 未定義/nil
  • false
功能

必須不允許新增超出下列清單的其他功能。

受限欄位

  • 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 磁碟區。

受限欄位

  • spec.volumes[*].hostPath

允許的值

  • 未定義/nil
主機連接埠

應完全不允許 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

允許的值

  • 未定義/nil
  • 預設
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 強化的最佳實務,但會犧牲一些相容性。 它適用於安全至關重要的應用程式的運營商和開發人員,以及較低信任的使用者。以下列出的控制項應被強制執行/禁止

Restricted 原則規範
控制項策略
Baseline 原則中的所有內容
Volume 類型

Restricted 原則僅允許以下 volume 類型。

受限欄位

  • spec.volumes[*]

允許的值

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

允許的值

  • false
以非 root 身分執行

必須要求容器以非 root 使用者身分執行。

受限欄位

  • spec.securityContext.runAsNonRoot
  • spec.containers[*].securityContext.runAsNonRoot
  • spec.initContainers[*].securityContext.runAsNonRoot
  • spec.ephemeralContainers[*].securityContext.runAsNonRoot

允許的值

  • true
如果 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

允許的值

  • 任何非零值
  • 未定義/null
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

允許的值

  • RuntimeDefault
  • Localhost
如果 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

允許的值

  • 包含 ALL 的任何功能列表

受限欄位

  • spec.containers[*].securityContext.capabilities.add
  • spec.initContainers[*].securityContext.capabilities.add
  • spec.ephemeralContainers[*].securityContext.capabilities.add

允許的值

  • 未定義/nil
  • NET_BIND_SERVICE

原則實例化

將原則定義與原則實例化分離,可以在整個叢集中實現對原則的共同理解和一致的語言,而與底層的強制執行機制無關。

隨著機制的成熟,它們將在下面按每個原則進行定義。此處未定義個別原則的強制執行方法。

Pod 安全准入控制器

替代方案

Kubernetes 生態系統中正在開發其他強制執行原則的替代方案,例如

Pod OS 欄位

Kubernetes 允許您使用執行 Linux 或 Windows 的節點。您可以在一個叢集中混合使用這兩種節點。Kubernetes 中的 Windows 與基於 Linux 的工作負載相比,有一些限制和差異。具體來說,許多 Pod securityContext 欄位 在 Windows 上無效

Restricted Pod 安全標準變更

Kubernetes v1.25 中進行的另一個重要變更是,Restricted 原則已更新為使用 pod.spec.os.name 欄位。根據 OS 名稱,可以為其他 OS 放寬特定於特定 OS 的某些原則。

特定於 OS 的原則控制項

只有在 .spec.os.name 不是 windows 時,才需要限制以下控制項

  • 權限提升
  • Seccomp
  • Linux 功能

使用者命名空間

使用者命名空間是一項僅限 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 網站指南

在提出新增額外協力廠商連結的變更之前,您應該閱讀內容指南

上次修改時間:2024 年 7 月 23 日下午 12:19 PST:PSS: add container_engine_t to allowed list of selinux types (06aff012a2)