还在裸奔运行容器？签名验证让你的镜像安全提升10倍，现在不做就晚了

第一章：还在裸奔运行容器？镜像安全的致命隐患

在现代云原生架构中，容器技术已成为应用部署的核心载体。然而，许多团队在追求快速交付的同时，忽视了容器镜像本身的安全性，导致系统暴露在严重风险之中。使用未经验证的第三方镜像或构建过程中引入恶意依赖，可能让攻击者轻易获取主机权限、窃取敏感数据，甚至横向渗透整个集群。

镜像来源不可信带来的风险

从公共镜像仓库（如 Docker Hub）拉取镜像时，若未验证发布者身份和镜像完整性，极有可能运行包含后门程序或挖矿脚本的恶意镜像。例如，某些看似正常的 Nginx 镜像内部可能预装了 SSH 后门或定时任务脚本。

• 使用官方认证（Official）或可信发布者（Verified Publisher）镜像
• 启用内容信任机制，如 Docker Content Trust (DCT)
• 定期扫描镜像漏洞并建立准入策略

实施镜像漏洞扫描

可借助开源工具 Trivy 或商业平台 Aqua Security 对镜像进行静态分析。以下为使用 Trivy 扫描本地镜像的示例：

# 安装 Trivy（以 Linux 为例） wget https://github.com/aquasecurity/trivy/releases/latest/download/trivy_0.48.0_Linux-64bit.tar.gz tar zxvf trivy_0.48.0_Linux-64bit.tar.gz sudo mv trivy /usr/local/bin/ # 扫描指定镜像中的漏洞 trivy image nginx:1.25-alpine # 输出包括 CVE 编号、严重等级、受影响组件及修复建议

最小化基础镜像减少攻击面

选择轻量且维护活跃的基础镜像能有效降低风险。对比常见基础镜像的安全特性：

镜像类型	大小（约）	安全优势
alpine:latest	5.6MB	小巧，软件包少，攻击面小
debian:slim	80MB	官方维护，更新及时
ubuntu:latest	77MB	生态丰富，但默认安装较多服务

第二章：深入理解容器镜像签名与验证机制

2.1 镜像签名的基本原理与加密技术

镜像签名是保障容器镜像完整性和来源可信的核心机制，依赖于非对称加密技术实现。私钥用于生成数字签名，公钥则供用户验证镜像未被篡改。

核心加密流程

常见的实现基于 RSA 或 ECDSA 算法，对镜像摘要进行签名。例如使用 OpenSSL 对镜像哈希值签名：

# 生成镜像摘要 sha256sum image.tar > image.digest # 使用私钥签名 openssl dgst -sha256 -sign private.key -out image.sig image.digest

该过程确保只有持有私钥的发布者能生成有效签名，提升供应链安全性。

验证机制对比

方法	安全性	适用场景
SHA256 + RSA	高	企业级镜像仓库
SHA256 + ECDSA	极高	高安全要求环境

2.2 基于公钥基础设施（PKI）的信任链构建

公钥基础设施（PKI）是现代网络安全的基石，通过数字证书和加密机制实现身份认证与数据完整性保障。其核心在于构建一条可验证的信任链，从受信任的根证书颁发机构（CA）逐级向下延伸。

信任链的层级结构

典型的PKI信任链包含以下层级：

• 根CA：自签名证书，预置于操作系统或浏览器中
• 中间CA：由根CA签发，用于隔离和扩展签发能力
• 终端实体证书：用于服务器、客户端或设备的身份认证

证书验证过程示例

在TLS握手过程中，客户端会逐级验证证书签名：

// 伪代码：证书链验证逻辑 func VerifyChain(cert *x509.Certificate, intermediates []*x509.Certificate) error { roots := x509.NewCertPool() roots.AddCert(rootCA) // 加载可信根 opts := x509.VerifyOptions{ Roots: roots, Intermediates: x509.NewCertPool(), KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth}, } _, err := cert.Verify(opts) return err // 返回验证结果 }

上述代码展示了如何使用Go语言标准库验证证书链。VerifyOptions配置了信任根、中间证书及预期用途，确保整个链条的签名有效且未被篡改。

典型PKI架构中的角色

角色	职责
CA	签发和吊销数字证书
RA	验证申请者身份信息
OCSP响应器	提供实时证书状态查询

2.3 OCI镜像格式与签名元数据存储方式

OCI（开放容器倡议）镜像格式定义了容器镜像的标准化结构，确保跨平台兼容性。其核心由镜像清单（Image Manifest）、文件系统层和配置对象组成。

镜像结构组成

• Manifest：描述镜像的JSON文件，列出各层摘要及配置引用
• Config Blob：包含启动命令、环境变量等元信息
• Layer Tarballs：只读文件系统增量包，按顺序叠加运行

签名元数据存储机制

数字签名通过签名人附加元数据实现，通常以独立对象形式存储于镜像仓库中，与清单哈希绑定。常见方案如Cosign采用SigStore体系，将签名存为特殊标签对象。

{ "schemaVersion": 2, "manifests": [ { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:abc123...", "size": 768, "annotations": { "io.sigstore.signature": "base64-encoded-signature" } } ] }

该代码展示了一个带签名注解的OCI索引片段，annotations字段嵌入了基于标准的外部签名数据，实现元数据与镜像内容的解耦存储。

2.4 主流签名标准对比：Cosign、Notary与DCT

在容器镜像和软件制品的可信验证领域，Cosign、Notary 与 DCT（Digital Container Trust）代表了当前主流的签名机制。它们在架构设计与使用场景上各有侧重。

核心特性对比

标准	密钥管理	签名存储	生态支持
Cosign	支持KMS、SSH密钥	OCI注册表附加层	广泛（Tekton、GitHub Actions）
Notary	基于TUF的层级密钥	独立元数据服务器	Docker生态为主
DCT	硬件绑定密钥	区块链存证	企业级平台

典型代码示例

cosign sign --key azurekms://mykey:v1 image:latest

该命令通过 Azure Key Vault 托管密钥对镜像进行签名，体现了 Cosign 对云原生密钥管理的良好集成能力。参数 `--key` 指定外部密钥源，避免本地私钥暴露，提升安全性。

2.5 签名验证在CI/CD流水线中的集成时机

在现代CI/CD流程中，签名验证应尽早引入以确保供应链安全。最佳实践是在代码提交后、构建前验证提交者签名，防止未授权变更进入流水线。

Git提交签名验证

通过钩子机制验证每次提交的GPG签名：

# 在 pre-receive 钩子中校验 while read oldrev newrev refname; do git log $oldrev..$newrev | grep -q "gpgsig" || exit 1 done

该脚本检查推送的提交是否包含GPG签名信息，缺失则中断流程。

构建阶段镜像签名校验

使用Cosign等工具在部署前验证容器镜像完整性：

• 拉取镜像后立即执行签名校验
• 仅允许通过可信CA签名的镜像运行
• 与私钥管理系统（如Hashicorp Vault）集成

第三章：构建端到端的镜像信任体系

3.1 制定组织级镜像签名策略与合规要求

在容器化环境中，确保镜像来源可信是安全体系的核心环节。组织需建立统一的镜像签名机制，强制要求所有生产环境部署的镜像必须经过数字签名验证。

签名策略核心要素

• 指定受信的私钥签名方，限制仅允许CI/CD流水线自动签名
• 集成公证服务（Notary）或Cosign实现Sigstore标准签名流程
• 设置Kubernetes准入控制器校验镜像签名状态

代码示例：使用Cosign签名验证

cosign verify --key cosign.pub registry.example.com/app:v1.2

该命令验证指定镜像是否由对应公钥签署。返回非零码则拒绝部署，可集成至Argo CD或Tekton等GitOps工具链中。

合规性检查表

项目	要求
签名覆盖率	100%生产镜像需签名
密钥轮换周期	每90天强制更新

3.2 使用Cosign实现私有镜像的签名与校验

在容器安全实践中，确保镜像来源可信至关重要。Cosign 作为 Sigstore 项目的一部分，为私有镜像提供无须复杂 PKI 的签名与校验能力。

安装与配置 Cosign

首先需安装 Cosign CLI 工具，并配置私有仓库访问权限：

wget https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 chmod +x cosign-linux-amd64 sudo mv cosign-linux-amd64 /usr/local/bin/cosign

该命令下载并安装适用于 Linux 的二进制文件，使其可在系统中全局调用。

镜像签名流程

使用密钥对镜像进行签名：

cosign generate-key-pair cosign sign --key cosign.key localhost:5000/myapp:v1

generate-key-pair生成密钥对，sign命令使用私钥对指定镜像签名，确保其完整性与来源可验证。

校验机制

在部署节点执行校验：

cosign verify --key cosign.pub localhost:5000/myapp:v1

该命令使用公钥验证镜像签名，防止被篡改或不可信的镜像运行，实现零信任安全模型下的镜像准入控制。

3.3 通过Sigstore实现零配置可信签名实践

在现代软件供应链安全中，Sigstore 提供了一种无需复杂配置即可实现代码与制品可信签名的解决方案。其核心依赖于公钥基础设施（PKI）的自动化和透明日志机制。

快速签名与验证流程

使用 `cosign` 工具可一键完成镜像签名：

cosign sign --key cosign.key your-registry/your-image:tag

该命令利用本地密钥对容器镜像生成数字签名，并将签名信息推送至镜像仓库。参数 `--key` 指定私钥路径，若省略则自动通过无证书公钥注册（Keyless模式）申请临时密钥。

Keyless 模式的工作机制

• 开发者通过 OIDC 身份认证触发签名请求
• Sigstore 自动生成短暂有效的密钥对
• 签名记录写入透明日志（Rekor），确保不可篡改

所有签名事件均可在 Rekor 日志中公开查询，构建了端到端可审计的信任链。

第四章：生产环境中的签名验证落地实践

4.1 在Kubernetes集群中启用Pod镜像策略控制

在Kubernetes中，确保Pod仅使用受信任的容器镜像是安全策略的关键环节。通过配置准入控制器与策略引擎，可实现对镜像来源的有效管控。

使用PodSecurityPolicy限制镜像来源（已弃用）

早期版本中可通过PodSecurityPolicy设置allowedHostPaths和镜像校验逻辑，但该资源已在v1.25弃用。

采用Gatekeeper实施签名验证

推荐使用OPA Gatekeeper定义约束模板，强制镜像必须来自私有仓库并经过签名：

apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata: name: require-private-registry spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: repos: - "harbor.internal/myproject"

上述策略拦截所有非指定仓库的镜像拉取请求，结合Cosign完成镜像签名验证，形成完整的软件供应链防护闭环。

4.2 结合OPA/Gatekeeper实现细粒度签名校验

在Kubernetes环境中，结合OPA（Open Policy Agent）与Gatekeeper可实现容器镜像的细粒度签名校验。通过编写策略模板，可强制要求部署的镜像必须来自可信仓库且具备有效签名。

策略定义示例

package k8s_imageregistry violation[{"msg": msg}] { input.review.object.spec.template.spec.containers[_].image := img not startswith(img, "registry.example.com") msg := sprintf("镜像源不合法: %v，必须来自可信仓库", [img]) }

该Rego策略检查Pod中所有容器的镜像是否以指定前缀开头，若不符合则触发拒绝规则。通过Gatekeeper的`Constraint`资源可动态加载此类策略。

集成流程

• 部署Gatekeeper控制器至集群
• 注册签名校验的ConstraintTemplate
• 创建具体约束规则（Constraint）限定镜像来源
• 配合Cosign等工具验证镜像签名完整性

4.3 私有Registry集成签名验证的完整配置流程

在企业级容器平台中，确保镜像来源可信至关重要。通过集成私有Registry与签名验证机制，可实现镜像的完整性校验。

启用Notary服务

Docker Notary是实现镜像签名的核心组件，需首先部署并关联至私有Registry：

docker run -d \ --name notary-server \ -e "SERVER_ADDR=0.0.0.0:4443" \ -v /path/to/config:/etc/notary/

该命令启动Notary服务，监听4443端口，配置文件中需指定TLS证书与数据库连接参数。

客户端配置与策略设置

在Docker客户端启用内容信任：

1. 设置环境变量：export DOCKER_CONTENT_TRUST=1
2. 推送镜像时自动触发签名：docker push myregistry.local/image:v1

验证流程控制

阶段	操作	安全要求
拉取	检查元数据签名	必须由授权密钥签署
运行	校验镜像哈希一致性	禁止未签名标签执行

4.4 监控、告警与违规镜像运行的应急响应机制

实时监控与指标采集

通过 Prometheus 抓取容器运行时指标，结合 cAdvisor 监控容器资源使用情况。关键字段包括镜像哈希、启动时间、命名空间等，用于识别非法镜像。

- alert: UnauthorizedImageRunning expr: | kube_pod_container_info{image!~"registry\.corp\.com/.+"} for: 2m labels: severity: critical annotations: summary: "检测到未授权镜像运行" description: "Pod {{ $labels.pod }} 使用了非受信镜像 {{ $labels.image }}"

该告警规则持续监测非企业镜像仓库来源的容器镜像，一旦发现即触发告警。

自动化响应流程

告警触发后，联动 webhook 调用响应服务，执行隔离、日志留存与通知操作：

1. 暂停对应 Pod 运行（kubectl drain）
2. 提取容器内存与磁盘快照
3. 发送事件至 SIEM 系统并通知安全团队

第五章：未来展望：从签名到软件供应链全链路可信

随着 DevOps 流程的普及，攻击者越来越多地将目标转向构建、分发环节。单一的代码签名已无法满足现代软件交付的安全需求，全链路可信成为必然方向。

构建可验证的发布流程

使用 Sigstore 实现 CI/CD 中的自动签名与验证，确保每个构件来源可信。例如，在 GitHub Actions 中集成 cosign：

- name: Sign container uses: sigstore/cosign-github-action@v2 with: command: sign image: ghcr.io/example/app:v1.0 key: ${{ secrets.COSIGN_KEY }}

依赖项透明化管理

通过引入 SBOM（Software Bill of Materials），可清晰追踪所有组件来源。主流格式如 SPDX、CycloneDX 可被自动化工具解析并集成至安全门禁策略中。

• 生成 SBOM 使用 Syft 扫描镜像或文件系统
• 将 SBOM 上传至私有仓库并与制品绑定
• 在部署前由 Chainguard Enforce 或 Grype 验证漏洞与许可风险

端到端信任链构建

阶段	技术手段	验证机制
开发	开发者身份绑定 OpenID + Fulcio 证书签发	Git 提交签名可追溯
构建	Tekton 或 GitHub Actions 集成透明日志（Rekor）	每次构建记录上链，不可篡改
部署	Kubernetes Admission Controller 校验镜像签名	未签名或无效签名拒绝运行