4、容器镜像安全基线:镜像扫描原理、Trivy工具集成、Clair工具集成、镜像签名与验证(Cosign)

4.1 容器镜像安全基线概述

容器镜像作为云原生应用交付的核心载体,其安全性直接决定生产环境的攻击面。镜像安全基线要求在构建、存储、部署全链路中,对镜像内容进行漏洞扫描、配置合规检查、敏感信息检测及完整性验证。本章聚焦于镜像扫描原理、主流工具(Trivy、Clair)的流水线集成,以及基于 Cosign 的镜像签名与验证机制。

核心原则: 未经扫描的镜像禁止推送到生产仓库;未经签名的镜像禁止在生产集群中运行。

4.2 镜像扫描原理

镜像扫描的核心流程包括:镜像层解析、软件物料清单(SBOM)提取、漏洞数据库匹配、风险评级输出。

  1. 层解析: 解压镜像各层文件系统,识别已安装的包管理器(如 apt、yum、apk)及语言依赖文件(如 package.json、requirements.txt)。
  2. SBOM 生成: 提取所有组件名称、版本号、许可证信息,形成结构化清单。
  3. 漏洞匹配: 将组件版本与 CVE 数据库(如 NVD、RedHat OVAL、GitHub Advisory)进行交叉比对。
  4. 风险评级: 根据 CVSS 分数、可利用性、修复状态输出严重等级(Critical / High / Medium / Low)。
扫描时机: 建议在 CI 构建阶段(镜像打包后)和 CD 部署前(仓库准入时)各执行一次扫描,形成双重校验。
镜像扫描原理流程 镜像层解析 SBOM 提取 漏洞匹配 风险评级 包管理器 / 依赖文件 CVE 数据库 CVSS 评分 / 严重等级

4.3 Trivy 工具集成

Trivy 是一款轻量级、高覆盖率的开源扫描器,支持容器镜像、文件系统、Git 仓库等多种扫描目标。其优势在于:内置多数据库、无需持久化存储、CI 友好。

4.3.1 流水线集成步骤

  1. 安装 Trivy: 在 CI 节点上通过官方脚本或容器方式部署。
  2. 执行扫描: 使用 trivy image 命令扫描构建后的镜像。
  3. 输出格式: 支持 JSON、SARIF、HTML 等格式,便于后续审计。
  4. 失败策略: 根据严重等级设置退出码,阻断高风险镜像的推送。
# 示例:在 GitLab CI 中集成 Trivy
trivy image --severity CRITICAL,HIGH --exit-code 1 --format json \
  --output trivy-report.json registry.example.com/app:${CI_COMMIT_SHA}

4.3.2 关键配置参数

参数 说明 推荐值
--severity 指定关注的漏洞等级 CRITICAL,HIGH
--exit-code 发现漏洞时返回非零退出码 1
--ignore-unfixed 忽略尚无修复方案的漏洞 按需启用
--cache-dir 漏洞数据库缓存路径 持久化卷挂载
注意: Trivy 首次运行需下载漏洞数据库(约 500MB),建议在 CI 中配置缓存或使用预加载的 sidecar 容器,避免每次构建重复下载。

4.4 Clair 工具集成

Clair 是 Red Hat 开源的静态分析工具,常用于私有镜像仓库的准入控制。Clair 采用 C/S 架构:Clair API 负责漏洞匹配,Clairctl 或 Harbor 作为客户端发起扫描请求。

4.4.1 架构与集成方式

  • 部署 Clair: 以容器方式运行,连接 PostgreSQL 数据库存储漏洞数据。
  • 配置更新器: 定期同步上游漏洞源(如 RedHat OVAL、Debian Security Tracker)。
  • API 调用: 通过 POST /v1/layers 推送镜像层信息,GET /v1/layers/{id}?vulnerabilities 获取漏洞列表。
  • Harbor 集成: 在 Harbor 中启用 Clair 作为默认扫描器,实现推送即扫描。
# 使用 curl 调用 Clair API 示例
# 1. 推送镜像层
curl -X POST http://clair:6060/v1/layers \
  -H "Content-Type: application/json" \
  -d '{"layer": {"name": "sha256:abc123", "path": "/tmp/layer.tar", "parent": "sha256:def456"}}'

# 2. 查询漏洞
curl http://clair:6060/v1/layers/sha256:abc123?vulnerabilities

4.4.2 Trivy 与 Clair 对比

维度 Trivy Clair
部署复杂度 低(单二进制) 中(需数据库 + API 服务)
扫描速度 快(秒级) 中(依赖层推送)
数据库覆盖 多源聚合(NVD、RedHat、Ubuntu 等) 侧重 Red Hat 生态
CI 友好度 高(无状态) 中(需持久化服务)
仓库集成 需自定义脚本 原生支持 Harbor

4.5 镜像签名与验证(Cosign)

Cosign 是 Sigstore 项目下的容器镜像签名工具,支持密钥对、密钥管理服务(KMS)及无密钥(Keyless)签名模式。签名信息存储在镜像仓库的 OCI 制品中,验证时无需额外存储。

4.5.1 签名流程

  1. 生成密钥对: cosign generate-key-pair 生成 cosign.key 和 cosign.pub。
  2. 签名镜像: cosign sign --key cosign.key registry.example.com/app:tag。
  3. 存储签名: 签名以 OCI 制品形式推送到镜像仓库,与镜像共存。
# 生成密钥对
cosign generate-key-pair

# 使用私钥签名镜像
cosign sign --key cosign.key registry.example.com/app:v1.0

# 使用公钥验证镜像
cosign verify --key cosign.pub registry.example.com/app:v1.0

4.5.2 流水线验证策略

  • 部署前验证: 在 Kubernetes 准入控制器(如 Kyverno、OPA Gatekeeper)中调用 Cosign 验证,拒绝未签名镜像。
  • CI 验证: 在推送镜像后立即执行 cosign verify,确保签名有效。
  • Keyless 模式: 使用 Sigstore 公共信任根,无需管理私钥,适合开源项目。
最佳实践: 将公钥存储在 Kubernetes Secret 中,通过 Kyverno 策略强制所有 Pod 引用的镜像必须经过 Cosign 验证,实现运行时安全基线。
Cosign 签名与验证流程 开发者 / CI 构建 cosign sign 推送签名到仓库 镜像仓库 镜像 + .sig 制品 K8s 准入控制器 cosign verify 允许 / 拒绝部署

4.6 流水线集成检查清单

阶段 检查项 工具 / 方法 失败动作
构建 镜像漏洞扫描 Trivy / Clair 阻断推送
构建 敏感信息检测 Trivy --scanners secret 阻断推送
推送 镜像签名 Cosign sign 告警 + 人工审核
部署 签名验证 Cosign verify + Kyverno 拒绝创建 Pod
运行时 周期性重新扫描 Trivy / Clair 定时任务 通知 + 隔离
安全基线总结: 容器镜像安全基线的落地依赖“扫描 + 签名 + 验证”三位一体。Trivy 适合快速 CI 集成,Clair 适合仓库级持续扫描,Cosign 提供完整性保障。三者结合可构建从构建到运行时的全链路镜像安全防线。