Pod 安全标准
详细了解 Pod 安全标准中定义的不同策略级别。
Pod 安全标准定义了三种不同的策略,以广泛涵盖安全范围。这些策略是累积的,从高度宽松到高度严格。本指南概述了每项策略的要求。
配置文件 | 描述 |
---|
特权 | 不受限制的策略,提供最广泛的权限级别。此策略允许已知的权限提升。 |
基线 | 最小限制策略,可防止已知的权限提升。允许默认(最小指定)Pod 配置。 |
受限 | 高度受限的策略,遵循当前的 Pod 加固最佳实践。 |
配置文件详细信息
特权
特权策略是故意开放的,并且完全不受限制。 这种类型的策略通常针对由特权的受信任用户管理的系统级和基础设施级工作负载。
特权策略由没有限制来定义。默认允许机制(例如 gatekeeper)可能默认情况下是特权的。相反,对于默认拒绝机制(例如 Pod 安全策略),特权策略应禁用所有限制。
基线
基线策略旨在简化常见容器化工作负载的采用,同时防止已知的权限提升。 此策略针对非关键应用程序的应用程序运营商和开发人员。应强制执行/禁止以下列出的控制措施
注意
在此表中,通配符 (*
) 表示列表中的所有元素。例如,spec.containers[*].securityContext
指的是所有定义的容器的安全上下文对象。如果任何列出的容器未满足要求,则整个 Pod 将无法通过验证。基线策略规范控制 | 策略 |
---|
主机进程 | Windows Pod 提供运行主机进程容器的能力,这使您可以访问 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
允许的值 - 未定义/空
AUDIT_WRITE CHOWN DAC_OVERRIDE FOWNER FSETID KILL MKNOD NET_BIND_SERVICE SETFCAP SETGID SETPCAP SETUID SYS_CHROOT
|
主机路径卷 | 必须禁止主机路径卷。 受限字段 允许的值 |
主机端口 | 应完全禁止主机端口(推荐)或限制为已知列表 受限字段 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
允许的值
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
受限字段 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
允许的值 |
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
指的是所有定义的容器的安全上下文对象。如果任何列出的容器未满足要求,则整个 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+) | 不应允许权限提升(例如通过设置用户 ID 或设置组 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 安全已更新为使用 pod.spec.os.name
字段。根据操作系统名称,可以放宽特定于特定操作系统的某些策略,以适用于其他操作系统。
特定于操作系统的策略控制
仅当 .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 网站指南。
在提出添加额外第三方链接的更改之前,您应该阅读 内容指南。