容器最小权限需要同时检查运行用户、capabilities、特权模式、宿主挂载与管理接口，不能只改一个用户字段。
把应用用户从 root 改为普通用户是有价值的一步，但容器仍可能通过过宽的能力、宿主目录挂载或管理接口取得不应有的访问。验收应检查实际运行时配置，而不只是 Dockerfile。
先列业务真正需要的能力
记录应用需要写入的目录、监听的端口、调用的设备和外部服务。把临时数据与持久数据区分开，明确哪些路径必须可写，哪些只需要读取。不要因为一个目录权限错误就把整个容器设为特权模式。
Docker 官方安全文档说明，Linux capabilities 可以细分特权，默认能力集合与挂载仍可能影响隔离。普通应用应尽量减少所需能力，并审查访问 Docker 管理接口和宿主资源的路径。
逐项核对运行配置
- 主进程实际以什么用户运行，启动脚本是否又切回高权限用户。
- 是否使用 privileged、额外 capabilities、宿主网络或宿主进程命名空间。
- 挂载了哪些宿主目录、设备和套接字，读写范围是否必要。
- 是否能够按业务需求使用只读根文件系统，并为确需写入的路径提供有限空间。
- 资源限制和默认安全机制是否因排障被长期移除。
用功能回归证明收紧可行
在测试环境逐步减少权限，覆盖启动、健康检查、日志、文件处理与重启。失败时定位具体缺失能力或目录，给出最小修正，而不是恢复所有权限。验证应用可以完成工作，同时无法访问明确不需要的宿主测试资源。
非 root 与 rootless 是不同概念，是否采用后者应结合平台支持与运维需求评估。容器也不是虚拟机式的绝对边界；宿主内核、运行时与镜像依赖仍需要持续维护。
参考：Docker：Docker Engine security。核对日期：2026年10月4日。
