Docker 安全加固：镜像小不是唯一目标

一、容器安全别只盯镜像大小

Docker 最佳实践里经常说镜像要小。小当然好，拉取快、攻击面少。但安全不只等于小。基础镜像来源、依赖漏洞、运行用户、文件权限、敏感信息、capabilities、只读文件系统，这些都影响容器安全。

一个 50MB 的镜像，如果以 root 运行、带着密钥、开放危险能力，也不安全。容器安全要从构建和运行两边一起看。

二、安全链路：构建和运行都要管

flowchart LR A[选择基础镜像] --> B[安装依赖] B --> C[漏洞扫描] C --> D[非 root 运行] D --> E[限制权限] E --> F[运行时监控]

构建阶段解决镜像来源和依赖问题，运行阶段限制权限和行为。只做一边，都不完整。

三、Dockerfile 示例：非 root 运行

FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --omit=dev COPY . . RUN addgroup -S app && adduser -S app -G app USER app CMD ["node", "server.js"]

非 root 运行是基础动作。即使应用被打穿，攻击者拿到的权限也更有限。当然，非 root 不是万能，还要配合文件权限和运行时限制。

四、工程边界：不要把密钥打进镜像

镜像是会被复制、缓存和扫描的。把.env、私钥、访问 token 打进镜像，是非常低级但常见的事故。配置和密钥应该通过 Secret、环境变量或外部配置系统注入，并控制访问范围。

取舍方面，多阶段构建能减小镜像，也能减少构建工具进入运行环境；但构建流程会复杂一些。安全扫描会增加 CI 时间，但能提前发现已知漏洞。对于生产镜像，这些成本值得。

还要限制运行时能力。Kubernetes 里可以设置runAsNonRoot、readOnlyRootFilesystem、allowPrivilegeEscalation: false，并丢弃不必要 capabilities。容器不是虚拟机，不要默认给它太多权限。

镜像标签也要治理。生产部署不要使用latest，应该使用不可变 tag 或 digest。否则同一个配置今天和明天拉到的镜像可能不同，排障会非常恶心。镜像是发布产物，不是临时文件。

构建上下文也要干净。.dockerignore里排除.git、本地缓存、测试数据、临时文件和密钥。很多镜像变大，不是应用真的大，而是把一堆无关文件打了进去。更糟的是，把内部配置和凭据一起打包。

最后，安全扫描要有处理流程。扫出漏洞后，谁判断风险，谁升级基础镜像，谁验证兼容性？没有流程，扫描报告只会堆在 CI 里变红背景板。

运行时还要限制网络访问。很多容器并不需要访问所有内网服务，可以用 NetworkPolicy 控制东西向流量。镜像里少漏洞是一层，运行时少权限是另一层。安全加固要分层，不要指望一个动作解决所有风险。

还要关注 SBOM。知道镜像里到底有哪些依赖，后续漏洞爆发时才能快速判断是否受影响。没有 SBOM，安全响应会变成全仓库猜谜。生产镜像不是黑盒，依赖清单要可追踪。

最后，安全策略要和开发体验平衡。限制太狠但没有文档，开发会绕过；规则清楚、模板好用，团队才愿意长期执行。

五、总结

Docker 安全加固不只是镜像小。基础镜像、依赖扫描、非 root、密钥管理、运行时权限和监控都要一起做。容器越轻，边界越要清楚。