3. 容器镜像安全

容器镜像安全是云原生安全面试中区分度极高的一类题目。面试官往往不会只问“你用过 Trivy 吗”，而是会沿着镜像的生命周期追问：镜像分层带来了哪些攻击面？Dockerfile 里哪些写法会埋雷？扫描工具报出的 CVE 该怎么判断优先级？私有仓库和供应链又该如何设防？本章围绕这条主线展开，帮助你把零散的工具知识串成可落地的安全实践。

一、镜像分层：理解安全问题的物理基础

Docker 镜像由一系列只读层（layer）叠加而成，每一层对应 Dockerfile 中的一条指令，最终由联合文件系统（OverlayFS 等）挂载为统一视图。容器启动时在最上层加一个可写层。这个机制直接决定了三件事：

第一，层是共享的。多个镜像若基于同一个基础镜像，会复用相同的底层，因此基础镜像一旦存在漏洞，影响面会成倍放大。第二，层是累积的。即使后续层删除了某个文件，该文件仍保留在历史层中，镜像体积不会减小，敏感信息也不会真正消失。第三，层是可追溯的。通过 docker history 可以查看每一层的构建指令，这既是审计手段，也是泄露风险点。

面试中常被问到的经典场景是：在 Dockerfile 中通过 ENV 或 RUN 写入密钥，随后用 RUN rm 删除。这种做法是无效的，因为密钥已经固化在中间层里。正确做法是使用构建参数（BuildKit 的 --secret）或运行时注入，避免密钥进入任何镜像层。

二、Dockerfile 安全实践：把风险挡在构建阶段

Dockerfile 是镜像的“源代码”，安全实践应从这里开始。以下是一份经过安全加固的示例，可作为面试中展示工程能力的素材：

# 使用固定 digest 的基础镜像，避免 tag 漂移
FROM node:20.11.1-alpine3.19@sha256:1a2b3c... AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

FROM node:20.11.1-alpine3.19@sha256:1a2b3c...
# 创建非 root 用户
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder --chown=app:app /app /app
USER app
EXPOSE 3000
ENTRYPOINT ["node", "server.js"]

这份示例体现了几个关键原则：基础镜像固定 digest，防止上游 tag 被篡改导致构建结果不可控；多阶段构建，把编译工具链留在 builder 阶段，运行镜像只保留产物，既减小体积又减少攻击面；非 root 运行，即使容器被突破，攻击者获得的权限也有限；使用 npm ci 而非 npm install，保证依赖版本与 lock 文件严格一致。

此外还需注意：避免使用 latest 标签；不要在 RUN 中执行 curl | bash 这类不可验证的远程脚本；COPY 时用 .dockerignore 排除 .git、.env、测试数据等；apt-get 安装后清理缓存以减小层体积。这些细节在面试中能体现你对构建链路的真实理解。

三、镜像扫描工具：Trivy 与 Clair 的定位差异

镜像扫描的核心是比对软件包清单与漏洞数据库。Trivy 和 Clair 是两类代表工具，理解它们的差异比记住命令更重要。

Trivy 是 Aqua 开源的 All-in-One 扫描器，安装简单，一条命令即可扫描镜像、文件系统、Git 仓库、Kubernetes 配置等。它默认从 GitHub Advisory、NVD 等源拉取漏洞库，支持 OS 包和语言级依赖（npm、pip、Go modules 等）。典型用法：

trivy image --severity HIGH,CRITICAL --ignore-unfixed \
  --exit-code 1 myregistry.example.com/app:1.4.2

这条命令只关注高危和严重漏洞，忽略尚无修复方案的条目，并在发现问题时返回非零退出码，可直接嵌入 CI 流水线作为质量门禁。输出会列出 CVE 编号、受影响包、当前版本、修复版本和严重等级，便于判断处置优先级。

Clair 则更偏向服务化架构，通常与 Harbor 等私有仓库集成，通过 API 提供扫描能力。它把漏洞数据存储在 PostgreSQL 中，适合大规模、持续性的镜像扫描场景。Clair 的 v4 版本引入了更细粒度的索引和匹配机制，但部署和维护成本高于 Trivy。

面试中的判断依据可以这样表述：CI 阶段追求快速反馈和易集成，优先 Trivy；仓库侧需要持续扫描存量镜像并统一展示，Clair 与 Harbor 的组合更合适。两者并非互斥，很多团队会在构建时用 Trivy 卡门禁，在仓库侧用 Clair 做持续监控。

四、私有仓库安全与供应链风险

私有仓库是镜像分发的枢纽，一旦失守，影响的是整个集群。安全配置应覆盖以下层面：

访问控制：启用基于项目的 RBAC，区分推送、拉取、删除权限；禁止匿名拉取；对机器人账号使用最小权限的 token，并定期轮换。传输与存储：强制 HTTPS，配置受信任证书；启用镜像签名（Cosign/Notation）和内容信任（DCT），确保拉取的镜像确实由可信方构建。漏洞治理：开启仓库的自动扫描，对存量镜像设置保留策略，及时清理长期未更新的旧版本，避免“僵尸镜像”成为漏洞温床。

供应链风险则更隐蔽。典型攻击路径包括：上游基础镜像被投毒、依赖包被植入恶意代码（如 event-stream 事件）、构建环境被入侵导致产物被篡改。防御思路是建立可验证的信任链：使用 SBOM（软件物料清单）记录镜像中的所有组件，推荐 SPDX 或 CycloneDX 格式；对镜像进行签名并在准入控制器（如 Kyverno、OPA Gatekeeper）中校验签名；对关键镜像固定 digest 而非 tag。这样即使仓库被入侵，攻击者也无法用未签名的镜像替换原有产物。

五、面试实战：一条完整的回答链路

当被问到“如何保障容器镜像安全”时，可以按生命周期组织回答：构建阶段——固定基础镜像 digest、多阶段构建、非 root 用户、.dockerignore 排除敏感文件、不在层中写入密钥；扫描阶段——CI 中集成 Trivy 设置严重等级门禁，仓库侧用 Clair 持续扫描；分发阶段——私有仓库启用 RBAC 和 HTTPS，镜像签名并校验；运行阶段——准入控制器校验签名和 digest，限制特权容器。这条链路既展示了工具能力，也体现了对分层机制和供应链的整体理解，是面试中较有说服力的回答结构。

需要提醒的是，扫描工具报出的漏洞数量往往很多，面试官更关注你如何判断优先级：优先修复有公开利用代码（Exploit Available）的漏洞、运行镜像中实际加载的组件、以及暴露在公网的服务所依赖的包。对于“无修复版本”的漏洞，应评估缓解措施而非盲目等待。这种基于风险的判断能力，才是云原生安全工程师的核心竞争力。