Docker 运行时安全：容器隔离不是万能护盾
一、容器能跑，不代表隔离足够安全
Docker 让应用交付变轻，但容器不是虚拟机。容器共享宿主机内核，隔离依赖 namespace、cgroup、capabilities、seccomp 和文件系统权限。默认配置如果过宽，容器逃逸和越权风险会升高。
运行时安全不是镜像扫描的替代。镜像干净只能说明构建材料较可信，容器运行时仍可能因为权限过大、挂载危险目录或特权模式而出问题。
二、权限要最小化
flowchart TD
A[容器启动] --> B[非 root 用户]
B --> C[Drop Capabilities]
C --> D[只读文件系统]
D --> E[Seccomp/AppArmor]
E --> F[运行时监控]
容器应尽量使用非 root 用户运行，去掉不需要的 Linux capabilities。很多业务容器不需要 NET_ADMIN、SYS_ADMIN 这类高权限能力。少给一个权限，就少一个攻击面。
只读根文件系统也很有用。应用需要写入的目录可以单独挂载临时卷。这样即使进程被入侵，攻击者能修改的范围也受限。
三、配置要写进部署模板
securityContext:
runAsNonRoot: true
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
安全配置不能靠人工记忆。应该写进 Helm Chart、Kustomize 或平台模板。新服务默认继承安全基线，特殊服务需要明确申请例外。
seccomp 和 AppArmor 可以限制系统调用和行为。不是所有团队一开始都能写很细的策略，但至少可以使用 runtime default，避免完全裸奔。
bad: privileged: true
better: explicit capabilities + seccomp default
四、运行时要有告警
安全不是配置一次就结束。容器运行时如果出现异常 shell、敏感路径访问、提权尝试、异常网络连接，都应该被监控。Falco 这类工具可以提供运行时事件检测。
还要审计危险挂载。把 Docker socket、宿主机根目录或敏感配置挂进容器，是高风险行为。平台应该在准入阶段拦截，而不是等运行后再发现。
镜像启动命令也要检查。容器里如果默认启动 shell、调试端口或多余守护进程，攻击面会变大。生产镜像应只包含运行所需进程，调试工具可以放到临时诊断镜像里。
网络策略同样重要。容器被入侵后，如果能访问所有内网服务，风险会迅速扩大。Kubernetes 里可以用 NetworkPolicy 限制服务之间的访问，只开放必要端口。
密钥不能写进镜像。环境变量和挂载文件也要控制权限和轮换周期。运行时安全不仅是进程权限，也是凭证生命周期管理。
最后，安全基线要进入准入控制。OPA Gatekeeper 或 Kyverno 可以拦截特权容器、危险能力和不合规挂载。自动化拦截比人工 Review 更稳定。
运行时安全还要结合镜像签名。部署前验证镜像来源，运行时限制只能拉取可信仓库，可以减少供应链风险。即使攻击者推了同名镜像，集群也不应无条件运行。
日志和审计要覆盖容器启动参数。谁部署了特权容器，什么时候挂载了敏感目录，使用了哪个镜像摘要，都应该能查到。安全事件发生后，审计链路比口头回忆可靠。
五、总结
Docker 运行时安全要做到非 root、最小权限、只读文件系统、seccomp/AppArmor 和运行时监控。
容器隔离不是万能护盾。真正安全的容器，是从镜像到运行时都把权限收紧。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2609_95049439/article/details/162588596
