容器内排障的权限边界：三个最危险的默认值

容器里的 /proc 是命名空间视图，看到的进程只是容器内的

最小权限不是一句口号，是三个具体动作：降权运行、限定目录、收敛网络。

先说结论

把「它能碰到什么」缩到最小，剩下的漏洞才谈得上「影响有限」。

• 用独立低权限账号运行，别用 root
• 数据目录 750，含密钥的配置 600
• 只监听需要的地址，管理端口不对外
• 凭据不写进镜像与仓库
• 定期核对权限，别让临时改动留下来

三个默认值

这三个是审计里出现频率最高的：

• 以 root 运行：一个 RCE 就是整机失守
• 监听 0.0.0.0：管理接口直接暴露在公网
• 目录 777：任何进程都能改配置和数据库

怎么改

docker stop 先发 SIGTERM，等 10 秒再 SIGKILL，退出码 137 就是被强杀。

这个服务的几个安全事实

和它自身机制相关的权限细节：

• docker inspect 的 State.Pid 是宿主上的 PID，用它才能 nsenter 进命名空间
• --net=container:x 让调试容器共用网络命名空间，可以用它的 curl 访问对端的回环地址
• 容器里的 /proc 是命名空间视图，看到的进程只是容器内的

凭据怎么放

能不用密码就不用：密钥、短期令牌、专用账号，三层叠加最省心。

自查清单

每月花十分钟做一遍：确认运行身份、检查监听端口、复核目录权限、清理临时账号、确认备份可恢复。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• distroless 与 scratch 镜像里没有 sh，docker exec 会直接报 not found
• docker cp 在容器已退出但未删除时仍可用，容器一删就没了
• 往生产容器里 exec 装 curl，重启后全部丢失
• docker logs 里看不到崩溃原因，其实是进程被 SIGKILL 没留日志
• 在容器里改配置不落盘，下一次发布被镜像覆盖

权限给多了不会立刻出事，但出事的时候一定是因为它。