容器镜像安全是贯穿构建、存储、分发、部署、运行的全链路防护：构建阶段优选官方精简镜像、多阶段构建、依赖锁定与非root用户；扫描需结合SBOM与可达性分析；分发须签名验证与准入控制；运行时启用PSA、eBPF监控与网络策略。
容器镜像安全不是一次扫描就完事的事，它是一条贯穿构建、存储、分发、部署、运行的连续链路。任何一个环节松动，都可能让高危漏洞或恶意代码进入生产环境。
构建阶段：从源头卡住风险
镜像构建是安全防线的第一关。基础镜像选型直接影响整体风险面——优先选用官方维护、定期更新的精简镜像（如 alpine:3.18 或 distroless），避免使用 latest 标签；采用多阶段构建，分离编译环境与运行时环境，剔除构建工具、调试器等非必要组件；强制启用依赖锁定（如 go.sum、package-lock.json），确保每次构建可复现。
- 在 Dockerfile 中显式指定用户：
RUN addgroup -g 61 -r appgroup && adduser -S appuser -u 61，再用USER appuser切换非 root 身份运行 - 禁止在镜像中硬编码密钥或凭证，改用 Kubernetes Secret 或外部凭据管理服务注入
- 构建过程集成 SBOM（软件物料清单）生成工具（如 Syft），为后续漏洞比对提供依据
扫描与评估：不止看“有多少漏洞”
扫描本身不等于安全，关键在如何解读和响应。用 Trivy 扫描时，建议按严重等级过滤：trivy image --severity HIGH,CRITICAL nginx:1.23.3；输出 JSON 报告便于自动化分析；结合 Grype 与 SBOM 匹配，识别真实受影响组件而非仅依赖版本号匹配。
- 区分漏洞是否可达：例如 openssl 漏洞只在启用 TLS 的服务中才构成实际威胁
- 关注修复时效性：高危 CVE 从公开到镜像修复应控制在 24 小时内，普通漏洞目标修复周期 ≤7 天
- 建立基线策略：对基础镜像设定每周自动重建机制，避免长期使用陈旧层
分发与准入：让恶意镜像进不来
镜像推送至仓库后，必须绑定可信身份。使用 Cosign 对镜像签名，确保来源可追溯；在 Kubernetes 集群中通过 Kyverno 或 OPA Gatekeeper 实施准入控制，拒绝未签名、未通过漏洞阈值（如无 CRITICAL 漏洞）、未匹配 SBOM 签名的镜像拉取。
- 私有镜像仓库需开启 HTTPS 和认证鉴权，禁用匿名 pull
- 标签策略统一采用语义化版本（如 v2.13.3），禁用 latest 或时间戳类模糊标签用于生产
- 镜像拉取策略设为 IfNotPresent，配合镜像 digest（sha256）校验，杜绝中间人篡改
运行时防护：守住最后一道门
即使镜像通过所有前置检查，运行时仍需持续监控。启用 Pod 安全策略（PSP）或 Pod Security Admission（PSA），限制特权模式、宿主机路径挂载、CAPABILITY 权限；部署 eBPF 基础的运行时行为监控（如 Cilium 或 Falco），捕获异常进程、敏感文件读写、横向网络连接等可疑行为。
- 设置资源限制（CPU/memory requests/limits），防止单个容器耗尽节点资源引发拒绝服务
- 网络层面默认拒绝所有 pod 间通信，仅按需开通命名空间/标签级 NetworkPolicy
- 定期轮换镜像仓库访问凭证与集群 service account token，缩短密钥生命周期
