容器权限安全边界由命名空间、cgroups和capabilities共同定义，需从镜像构建贯穿运行时：启用userns实现uid映射，--cap-drop=all后按需添加能力，只读根文件系统配合tmpfs与显式卷权限，强制启用seccomp/apparmor/selinux纵深防御。
容器权限安全边界不是一道“墙”，而是一组可配置、可叠加的隔离层。它不依赖硬件虚拟化，而是通过 Linux 内核机制在进程级实现资源可见性与操作能力的限制。关键在于：权限控制必须从镜像构建开始，贯穿运行时配置，最终由命名空间、cgroups 和 capabilities 共同定义实际边界。
用户身份与命名空间是权限起点
容器内 UID 0（root）不等于宿主机 root，但默认映射下仍拥有高风险操作能力。必须显式创建非特权用户，并启用 User 命名空间（如 Docker 的 --userns-remap 或 Kubernetes 的 runAsNonRoot: true）。这能将容器内 root 映射为宿主机上的普通 UID，从根本上阻断多数逃逸路径。若未启用 UserNS，仅靠 USER 指令切换用户仍存在挂载点、proc/sysfs 等路径越权风险。
Capabilities 是权限开关，不是功能开关
Linux 能力（Capabilities）控制的是“能不能执行某个系统调用”，而非“能不能启动某个服务”。常见误区是为运行 Nginx 就加 NET_ADMIN，其实只需 NET_BIND_SERVICE 即可绑定 80 端口。应始终以 --cap-drop=ALL 开始，再按需添加：
- NET_BIND_SERVICE：仅用于监听 1024 以下端口
- SETGID / SETUID：仅当应用明确需切换用户组时启用
- KILL：仅当需向其他容器进程发信号时启用
- 避免添加：SYS_ADMIN、NET_ADMIN、SYS_MODULE —— 这三类能力在 2026 年已关联超 67% 的容器逃逸漏洞
文件系统权限必须与挂载行为协同控制
只读根文件系统（--read-only）本身不安全，若同时挂载了可写卷（如 -v /host/data:/app/data）且权限宽松，攻击者仍可篡改配置或注入恶意二进制。正确做法是：
- 根文件系统设为只读
- 临时目录用 --tmpfs 挂载（如 /tmp、/run）
- 业务数据卷启用 uid/gid 显式映射（如 -v /host/data:/app/data:Z 或 :ro）
- 禁止挂载 /proc、/sys、/dev 等敏感路径，除非有强审计依据
安全模块是最后一道纵深防线
Seccomp、AppArmor 或 SELinux 不是可选项，而是生产环境强制项。它们在 capabilities 之上再过滤系统调用或资源访问行为：
- Seccomp：禁用危险调用如 clone（带 CLONE_NEWUSER）、mount、ptrace
- AppArmor：限制对特定路径（如 /etc/shadow）的读写，或禁止加载共享库
- SELinux：在启用了 MLS/MCS 的环境中，为容器进程打上 container_t 类型标签，实现策略强制
单一机制失效时，其余层仍可拦截攻击链。2026 年多起高危事件复盘显示，启用完整安全模块组合的集群，平均响应时间缩短 83%，横向移动成功率下降至 4.2%。
