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 --omitdev 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、密钥管理、运行时权限和监控都要一起做。容器越轻边界越要清楚。