K8s Pod securityContext配置安全风险及跨Pod控制能力问询

一、如何排查集群内的特权Pod #

直接用kubectl命令筛选所有设置privileged: true的Pod：

kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.containers[*].securityContext.privileged==true)]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'

二、securityContext各字段的安全风险 #

allowPrivilegeEscalation #

即使privileged: false，该字段设为true时，容器内进程可通过sudo、setuid/setgid程序等方式提升权限（比如从普通用户切换到root）。一旦提权成功，若容器挂载了宿主机敏感资源（如/var/run/docker.sock、/var/run/kubelet.sock），或绑定了高权限ServiceAccount，就可能突破容器隔离，操作宿主机或集群内其他Pod。

RunAsUser #

• 设为0（root用户）时，结合allowPrivilegeEscalation: true或特权Capabilities，风险会显著提升，因为root本身就拥有容器内的最高权限，更容易利用漏洞突破隔离。
• 设为普通用户时风险较低，但如果配合其他特权配置（如添加CAP_SYS_ADMIN），仍可能存在提权或越权操作的隐患。

ProcMount #

默认是DefaultProcMount，若设为Unmasked，容器能访问完整的/proc目录，包括宿主机进程的敏感信息（如进程环境变量、内存数据），攻击者可利用这些信息获取集群凭证（如ServiceAccount Token），进而操作其他Pod。

Capabilities #

添加特权能力会赋予容器超出普通权限的操作能力，即使privileged: false也可能带来高风险：

• CAP_SYS_ADMIN：允许挂载文件系统、修改系统参数，可突破容器隔离访问宿主机资源。
• CAP_NET_ADMIN：允许修改网络配置，比如创建隧道、劫持流量，可能干扰其他Pod的网络通信。
• CAP_SYS_PTRACE：允许调试其他进程，可读取进程内存中的敏感数据（如凭证）。

三、privileged: false但allowPrivilegeEscalation: true的隐患 #

这种配置确实存在安全风险：

1. 提权风险：容器内若存在sudo、su等提权工具，普通用户可切换到root，获得容器内最高权限。
2. 集群操作可能性：如果Pod绑定了高权限ServiceAccount（如cluster-admin），提权后可通过kubectl或集群API直接操作其他Pod（如删除、修改、查看Pod数据）。
3. 外部数据访问：只要网络策略允许，普通容器本身就能访问外部数据；提权后可能绕过应用层的访问限制（如读取容器内的敏感配置文件，进而获取外部服务的凭证）。

四、可控制集群内其他Pod/进程的securityContext组合 #

以下组合配合适当的集群权限（如ServiceAccount权限、宿主机资源挂载），可实现对其他Pod/进程的控制：

• 组合1：privileged: true + 绑定cluster-admin级别的ServiceAccount
  直接获得宿主机和集群的完全控制权，可任意操作所有Pod、节点及集群资源。
• 组合2：allowPrivilegeEscalation: true + RunAsUser: 0 + 添加CAP_SYS_ADMIN + 挂载宿主机/var/run/kubelet.sock或/var/run/docker.sock
  提权后通过socket直接控制宿主机上的容器，或调用kubelet API操作集群内的Pod。
• 组合3：allowPrivilegeEscalation: true + 容器内置sudo/setuid工具 + 绑定高权限ServiceAccount
  普通用户提权到root后，利用集群凭证调用API操作其他Pod。
• 组合4：ProcMount: Unmasked + 添加CAP_SYS_PTRACE
  通过读取宿主机或其他容器进程的内存，获取ServiceAccount Token等敏感凭证，进而利用凭证访问集群API操作Pod。

内容的提问来源于stack exchange，提问作者PJEM