非root sidecar重启同Pod跨容器进程所需capabilities

Linux 内核的信号发送权限默认遵循UID匹配规则：非特权进程发送信号时，自身的真实/有效UID必须和目标进程的真实/保存UID一致，否则会报Operation not permitted错误。
该场景下，sidecar容器运行用户是UID 12345，而nginx主进程属于root用户（UID 0），即使开启了shareProcessNamespace: true共享进程命名空间、添加了SYS_PTRACE能力，也无法绕过这个UID校验——SYS_PTRACE仅对ptrace调试类系统调用生效，和kill信号发送的权限校验无关。

只需要在sidecar容器的securityContext.capabilities.add列表中新增KILL capability即可，不需要给容器授予root权限，也不需要开启特权模式，原有的安全配置（禁止权限提升、只读根文件系统、非root用户运行）都可以保留。
修改后的sidecar配置片段如下：

- name: shell
  image: busybox:1.28
  securityContext:
    capabilities:
      add:
      - SYS_PTRACE # 如果不需要调试进程可以删除该项，发信号不依赖这个能力
      - KILL # 新增该项，绕过信号发送的UID校验
    runAsUser: 12345
    runAsGroup: 12345
    privileged: false
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
  stdin: true
  tty: true

1. 部署更新后的Pod

kubectl apply -f pod.yaml

2. 进入sidecar容器

kubectl attach -it nginx -c shell

3. 执行信号发送操作，无报错即代表权限配置生效，nginx会正常触发配置重载：

/ $ ps
PID   USER     TIME  COMMAND
 1 65535     0:00 /pause
 7 root      0:00 nginx: master process nginx -g daemon off;
/ $ kill -HUP 7
# 无错误输出即执行成功，可通过kubectl logs nginx -c nginx查看重载日志确认

• CAP_KILL的权限范围非常有限，仅允许进程绕过UID校验发送信号，不会带来提权、读写文件系统等额外风险，远比重用root运行sidecar安全。
• 如果集群开启了Pod Security Standards（Restricted级别）或者PodSecurityPolicy准入限制，需要确认策略允许容器添加KILL capability，否则配置会被准入控制器拦截。
• 如果sidecar仅用来做配置变更后的信号通知，不需要进程调试能力，可以删掉之前配置的SYS_PTRACE，进一步缩小攻击面。

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