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
能力(Capabilities)

必须禁止添加下列列表之外的额外能力。

受限字段

  • 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
主机端口

应该完全禁止使用主机端口(推荐),或仅限于已知列表。

受限字段

  • 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
  • Default
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
Sysctls

Sysctls 可以禁用安全机制或影响主机上的所有容器,除了允许的“安全”子集外,应予以禁止。如果 Sysctl 在容器或 Pod 中具有命名空间,并且与同一节点上的其他 Pod 或进程隔离,则被认为是安全的。

受限字段

  • 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 起)

受限

**“受限”策略旨在强制执行当前的 Pod 加固最佳实践,尽管这会牺牲一定的兼容性。** 它适用于安全关键应用程序的运营商和开发人员,以及较低信任度的用户。应强制执行/禁止以下列出的控制措施

受限策略规范
控制项策略
基线策略中的所有内容
卷类型

受限策略仅允许以下卷类型。

受限字段

  • 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+ 中,此策略仅适用于 Linuxspec.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+ 中,此策略仅适用于 Linuxspec.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 的节点。你可以在一个集群中混合使用这两种节点。与基于 Linux 的工作负载相比,Kubernetes 中的 Windows 存在一些限制和差异。具体来说,许多 Pod 的 securityContext 字段对 Windows 无效

受限 Pod 安全标准的变更

Kubernetes v1.25 中的另一个重要变更,是将受限策略更新为使用 pod.spec.os.name 字段。根据 OS 名称,可以放宽针对特定 OS 的某些策略,使其不应用于其他 OS。

OS 特定的策略控制项

仅当 .spec.os.name 不是 windows 时,才需要对以下控制项进行限制

  • 特权提升
  • Seccomp
  • Linux 能力

用户命名空间

用户命名空间是 Linux 独有的特性,用于以更高的隔离度运行工作负载。关于它们如何与 Pod 安全标准协同工作,请参阅使用用户命名空间的 Pod 文档

常见问题

为什么在“特权”和“基线”之间没有策略?

此处定义的三种策略具有从最安全(受限)到最不安全(特权)的清晰线性演进关系,并涵盖广泛的工作负载。高于基线策略所需的特权通常非常特定于应用程序,因此我们在此领域不提供标准策略。这并不是说在这种情况下应该始终使用特权策略,而是说此领域的策略需要根据具体情况来定义。

如果将来出现对其他策略的明确需求,SIG Auth 可能会重新考虑这一立场。

安全策略和安全上下文之间有什么区别?

安全上下文 在运行时配置 Pod 和容器。安全上下文作为 Pod manifest 中 Pod 和容器规约的一部分进行定义,并代表容器运行时的参数。

安全策略是控制平面机制,用于强制执行安全上下文中的特定设置以及安全上下文之外的其他相关参数。截至 2021 年 7 月,Pod 安全策略 已被弃用,取而代之的是内置的 Pod 安全准入控制器

沙箱 Pod 呢?

目前没有控制 Pod 是否被视为沙箱的标准 API。沙箱 Pod 可以通过使用沙箱运行时(例如 gVisor 或 Kata Containers)来识别,但对于什么是沙箱运行时没有标准定义。

沙箱工作负载所需的保护措施可能与其他工作负载不同。例如,当工作负载与底层内核隔离时,限制特权权限的需求会降低。这允许需要更高权限的工作负载仍能被隔离。

此外,沙箱工作负载的保护高度依赖于沙箱化方法。因此,没有针对所有沙箱工作负载推荐的单一策略。

此页面上的条目引用了提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者对这些第三方产品或项目不负责。有关更多详细信息,请参阅 CNCF 网站指南

在提议添加额外第三方链接的变更之前,应阅读内容指南

最后修改于 2025 年 2 月 24 日下午 9:31 PST:更新 pod-security-standards.md (d86a4b409a)