部署高安全容器系统需落实四层防护：权限控制（非root运行+最小能力限制）、敏感信息管理（secrets注入+零明文）、网络隔离（分网+默认拒绝）、运行时加固（seccomp+只读挂载）。
要部署具备高安全防护的容器化业务系统，关键不在堆砌工具，而在于把权限控制、网络隔离、敏感信息管理、运行时加固这四层逻辑真正落地。下面从实操角度讲清楚每一步该怎么做、为什么这么做、容易忽略什么。
用非 root 用户运行所有服务
默认以 root 运行容器是最大安全隐患之一。攻击者一旦突破应用层，就能直接获得容器内最高权限，进而横向渗透或逃逸到宿主机。
- 在 docker-compose.yml 中为每个服务显式指定
user字段，例如user: "1001:1001"或user: "appuser" - 确保基础镜像中已创建对应用户（如使用
openjdk:17-jdk-slim需提前在 Dockerfile 中adduser -u 1001 appuser） - 挂载的配置文件、日志目录等宿主机路径，需提前
chown 1001:1001赋权，否则容器启动失败
启用最小权限模型与运行时限制
即使用了非 root 用户，仍可能通过系统调用提权。需要用内核级机制进一步收窄能力边界。
- 用
cap_drop禁用全部能力，再按需cap_add补充，例如：cap_drop: ["ALL"]+cap_add: ["NET_BIND_SERVICE"] - 启用
seccomp默认策略（Docker 20.10+ 自带），或挂载自定义白名单 profile，拦截危险系统调用如execveat、ptrace - 对读写敏感数据的服务（如数据库、Dashboard），添加
read_only: true并仅挂载必要路径为可写
敏感配置与凭据零明文落地
密码、密钥、JWT Secret 等绝不能硬编码在 compose 文件或镜像里，也不能靠环境变量“掩耳盗铃”。
- 使用 Kubernetes Secrets 或 Docker Swarm secrets（若在 Swarm 模式下），通过
secrets:块挂载，内容自动出现在/run/secrets/xxx - 在 Compose 中避免
environment:直接写密钥；改用env_file:引入外部 .env 文件，并确保该文件不进 Git（加 .gitignore）、权限设为600 - 对 RocketMQ Dashboard、JeecgBoot 等后台系统，必须配置 HTTPS 和登录认证——证书用 volume 挂载，账号密码通过 secrets 注入，而非 application.properties 明文写死
网络分层与访问控制收敛
默认 bridge 网络相当于把所有服务放在同一张局域网里，一个服务被攻破，其余全暴露。
- 为不同安全等级的服务划分独立网络，例如：
backend（内部 API）、cache（Redis）、public（Nginx 入口），彼此默认不通 - 只在明确需要通信的服务间声明
networks:，例如 Web 服务连 backend，但不连 cache；Redis 只接受 backend 访问 - 对外暴露端口严格限制：Nginx 映射
80/443，Dashboard 映射8443，MySQL/Redis 等绝不映射到宿主机，仅通过内部网络连接
不复杂但容易忽略。安全不是加个 WAF 或开个 TLS 就完事，而是从用户、能力、凭据、网络四个维度一层层做减法。每少一条默认权限，就多一分确定性。
