4、容器镜像安全基线:镜像扫描原理、Trivy工具集成、Clair工具集成、镜像签名与验证(Cosign)
4.1 容器镜像安全基线概述
容器镜像作为云原生应用交付的核心载体,其安全性直接决定生产环境的攻击面。镜像安全基线要求在构建、存储、部署全链路中,对镜像内容进行漏洞扫描、配置合规检查、敏感信息检测及完整性验证。本章聚焦于镜像扫描原理、主流工具(Trivy、Clair)的流水线集成,以及基于 Cosign 的镜像签名与验证机制。
核心原则: 未经扫描的镜像禁止推送到生产仓库;未经签名的镜像禁止在生产集群中运行。
4.2 镜像扫描原理
镜像扫描的核心流程包括:镜像层解析、软件物料清单(SBOM)提取、漏洞数据库匹配、风险评级输出。
- 层解析: 解压镜像各层文件系统,识别已安装的包管理器(如 apt、yum、apk)及语言依赖文件(如 package.json、requirements.txt)。
- SBOM 生成: 提取所有组件名称、版本号、许可证信息,形成结构化清单。
- 漏洞匹配: 将组件版本与 CVE 数据库(如 NVD、RedHat OVAL、GitHub Advisory)进行交叉比对。
- 风险评级: 根据 CVSS 分数、可利用性、修复状态输出严重等级(Critical / High / Medium / Low)。
扫描时机: 建议在 CI 构建阶段(镜像打包后)和 CD 部署前(仓库准入时)各执行一次扫描,形成双重校验。
4.3 Trivy 工具集成
Trivy 是一款轻量级、高覆盖率的开源扫描器,支持容器镜像、文件系统、Git 仓库等多种扫描目标。其优势在于:内置多数据库、无需持久化存储、CI 友好。
4.3.1 流水线集成步骤
- 安装 Trivy: 在 CI 节点上通过官方脚本或容器方式部署。
- 执行扫描: 使用
trivy image命令扫描构建后的镜像。 - 输出格式: 支持 JSON、SARIF、HTML 等格式,便于后续审计。
- 失败策略: 根据严重等级设置退出码,阻断高风险镜像的推送。
# 示例:在 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 签名流程
- 生成密钥对:
cosign generate-key-pair生成cosign.key和cosign.pub。 - 签名镜像:
cosign sign --key cosign.key registry.example.com/app:tag。 - 存储签名: 签名以 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 验证,实现运行时安全基线。
4.6 流水线集成检查清单
| 阶段 | 检查项 | 工具 / 方法 | 失败动作 |
|---|---|---|---|
| 构建 | 镜像漏洞扫描 | Trivy / Clair | 阻断推送 |
| 构建 | 敏感信息检测 | Trivy --scanners secret | 阻断推送 |
| 推送 | 镜像签名 | Cosign sign | 告警 + 人工审核 |
| 部署 | 签名验证 | Cosign verify + Kyverno | 拒绝创建 Pod |
| 运行时 | 周期性重新扫描 | Trivy / Clair 定时任务 | 通知 + 隔离 |
安全基线总结: 容器镜像安全基线的落地依赖“扫描 + 签名 + 验证”三位一体。Trivy 适合快速 CI 集成,Clair 适合仓库级持续扫描,Cosign 提供完整性保障。三者结合可构建从构建到运行时的全链路镜像安全防线。