K8s Pod配置securityContext后执行jcmd报错无权限或无法打开套接字文件

问题成因 #

• JVM Attach API的权限校验规则限制
  JVM 提供的 Attach 机制（供 jcmd、jmap 等诊断工具调用）默认有严格的身份校验：

  1. 发起 Attach 请求的操作系统用户 UID 必须和 JVM 进程运行的 UID 完全一致，否则直接返回权限拒绝。
  2. JVM 启动时会在临时目录（默认 /tmp）创建监听 Attach 请求的套接字文件 .java_pid<进程号>，该文件默认权限为 0600，仅 JVM 所属用户拥有读写权限，其他用户无访问权限。
     你配置的 securityContext 指定 Java 进程以 UID 888 启动，若 exec 进入容器执行命令的用户身份和 888 不匹配，就会触发 permission denied 报错。

• root 用户执行报错的根因
  你使用 root 身份进入容器执行命令时，即便 root 拥有系统最高文件权限，JVM 的 Attach 校验逻辑仍然会拒绝非相同 UID 的请求。同时 jcmd 访问套接字失败后会尝试从 /proc/1/root/tmp/ 路径查找目标文件，而 K8s 默认的 Pod 安全限制（如 Seccomp 规则、AppArmor 配置）会禁止跨用户访问 /proc/<pid>/root 路径下的内容，最终抛出 unable to open socket file 报错。

• 删除 securityContext 后恢复正常的原因
  删除 securityContext 后，Pod 会默认以 root 用户启动容器内的 Java 进程，此时你 exec 进入容器的默认身份就是 root，和 JVM 运行 UID 完全匹配，所有权限校验自然通过，命令可以正常执行。

临时修复方案 #

1. 执行命令时主动指定和 JVM 运行一致的用户：

kubectl exec -it <你的Pod名> -- su -s /bin/bash 888 -c "jcmd 1 GC.heap_dump /tmp/heap_dump.hprof"

2. 在 Pod 的 securityContext 中补充 fsGroup: 888 配置，同时给 Java 进程添加启动参数 -Djdk.attach.allowAttachSelf=true 允许进程自身Attach请求。

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