K8s配置runAsNonRoot时如何为非root容器添加capabilities

两个问题导致你的配置不符合预期：

• YAML缩进错误：你贴出的配置中securityContext比同层级的name字段多缩进了4个空格，属于无效字段会被K8s直接忽略，这也是你进入容器后看到主进程仍以root身份运行的直接原因。
• 系统默认安全限制：Linux的capabilities机制默认仅向UID为0的root进程自动授予权限，非root进程默认无法直接继承capabilities.add中声明的权限，且配置runAsNonRoot: true时K8s会默认开启no_new_privs标志，阻止进程获得额外权限。

根据集群安全策略的严格程度，二选一即可：

方案1：放开权限提升限制（无需重构镜像） #

修正YAML缩进，添加allowPrivilegeEscalation: true配置，完整配置如下：

containers:
  - name: container-name
    # 注意securityContext和name字段保持相同缩进
    securityContext:
      capabilities:
        add: ["SETUID", "SYS_TIME"]
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      runAsUser: 1001
      allowPrivilegeEscalation: true

该配置生效后，非root用户启动的主进程即可正常持有你添加的SETUID、SYS_TIME权限。

方案2：镜像级设置文件capabilities（适合高安全等级集群） #

如果你的集群启用了Restricted级别的Pod安全标准，会强制禁止allowPrivilegeEscalation: true，此时需要在构建业务镜像时，直接为需要权限的可执行文件设置文件级capabilities，Dockerfile示例：

# 以node镜像为例，在复制完业务代码后执行setcap给二进制打权限标记
RUN setcap cap_setuid,cap_sys_time+eip /usr/local/bin/node

镜像构建完成后，Pod配置中不需要设置allowPrivilegeEscalation: true，只要保持runAsNonRoot: true、runAsUser: 1001和对应的capabilities.add配置即可，非root用户启动对应二进制时会自动获得绑定的权限。

配置生效后进入容器执行以下校验：

1. 执行id命令，确认输出的uid为1001，属于非root用户
2. 执行cat /proc/1/status | grep Cap，查看输出中的CapPrm和CapEff字段，若包含对应权限的掩码（SETUID和SYS_TIME对应的掩码为0000000002004000），则说明权限配置生效。

你之前测试移除runAsNonRoot: true后权限正常，是因为默认用root用户启动进程时，系统会自动将声明的capabilities加入进程权限集合，不需要额外放开权限提升限制。

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