2、容器镜像安全基础：镜像分层原理、常见漏洞类型（CVE、恶意软件）、镜像签名与验证概念
2.1 镜像分层原理与安全边界
容器镜像由一系列只读层（Layer）堆叠而成，每一层代表 Dockerfile 中的一条指令。分层结构在提升存储与分发效率的同时，也引入了独特的安全考量：
- 层共享风险：基础层（如
ubuntu:22.04）被多个镜像共用，一旦该层存在漏洞，所有依赖它的镜像均受影响。 - 层缓存污染：CI/CD 中若使用不可信的基础层缓存，可能将恶意软件带入构建产物。
- 层历史泄露：
docker history可查看每一层的内容与指令，敏感信息（密钥、密码）若未在后续层清理，仍可通过层 diff 恢复。
安全原则：最小基础镜像（如 distroless、scratch）+ 多阶段构建 + 层数精简，可显著降低攻击面。
2.2 常见漏洞类型：CVE 与恶意软件
容器镜像安全威胁主要分为两大类：已知漏洞（CVE）和主动植入的恶意软件。下表对比了二者的关键特征：
| 维度 | CVE（通用漏洞披露） | 恶意软件（Malware） |
|---|---|---|
| 来源 | 开源组件、系统库、应用依赖中的已知缺陷 | 攻击者主动植入的恶意代码（后门、挖矿、勒索） |
| 检测方式 | CVE 数据库匹配（NVD、RedHat、Debian） | 静态分析、行为检测、YARA 规则、病毒库 |
| 生命周期 | 从披露到修复（补丁发布） | 从植入到清除（持续演化变种） |
| 典型风险等级 | CVSS 评分（0-10），Critical/High/Medium/Low | 按危害程度分级（信息窃取、远程控制、破坏） |
| 修复策略 | 升级基础镜像 / 更新依赖版本 | 删除恶意层、重建镜像、审计供应链 |
实践建议：在 CI 流水线中集成
trivy、grype 或 snyk 进行镜像扫描，设置阻断策略（如：Critical 漏洞数 > 0 则禁止推送）。
2.3 镜像签名与验证概念
镜像签名通过非对称加密为镜像内容生成数字签名，确保镜像在构建后未被篡改，且可追溯发布者身份。核心流程如下：
- 签名：发布者使用私钥对镜像摘要（Digest）签名，生成签名文件并存储到 OCI 仓库或独立签名仓库。
- 分发：镜像与签名文件一同分发（或通过引用关联）。
- 验证：拉取方使用发布者公钥验证签名，确认镜像完整性与来源可信。
当前主流方案对比：
| 方案 | 签名格式 | 密钥管理 | 集成难度 | 适用场景 |
|---|---|---|---|---|
| Docker Content Trust (DCT) | Notary v1 | 本地 Yubikey / 文件 | 低（Docker 原生） | 小型团队、单仓库 |
| Cosign (Sigstore) | OIDC + 临时密钥对 | 无密钥 / 密钥对 / KMS | 中（CLI 工具） | CI/CD、多仓库、无密钥模式 |
| Notary v2 (OCI Artifact) | OCI 引用 + 签名 | KMS / 硬件模块 | 高（需 OCI 兼容仓库） | 企业级、合规要求 |
常见误区：镜像签名 ≠ 镜像加密。签名仅保证完整性与来源，不保护镜像内容在传输过程中的机密性。若需加密传输，应使用 TLS 或镜像加密方案（如 OCIcrypt）。
2.4 安全集成要点
- 策略即代码：在 Kubernetes 准入控制器（如 Kyverno、OPA/Gatekeeper）中强制要求镜像必须携带有效签名。
- 密钥轮换：定期轮换签名密钥，并维护公钥信任链（如 Sigstore 的 Fulcio 根证书）。
- 审计日志：记录每次签名与验证操作，便于事后追溯与合规审计。
- 回滚兼容：回滚到旧版本镜像时，需确保旧镜像的签名仍可被当前信任策略验证，或保留历史公钥。