如何用Notary和Cosign实现企业级Agent镜像签名？一文讲透

第一章：企业 Agent 的 Docker 镜像签名

在企业级容器化部署中，确保镜像来源的可信性和完整性至关重要。Docker 镜像签名机制通过数字签名验证镜像是否由可信方构建并未经篡改，是 DevSecOps 流程中的关键一环。启用内容信任（Content Trust）后，只有经过签名的镜像才能被拉取或运行，从而有效防止恶意镜像注入。

启用 Docker 内容信任

Docker 默认未开启内容信任功能，需通过环境变量激活：

# 启用内容信任
export DOCKER_CONTENT_TRUST=1

# 可选择设置为仅验证已签名镜像（不强制签名）
export DOCKER_CONTENT_TRUST_SERVER=https://notary.example.com

启用后，docker pull 和 docker run 将自动验证镜像签名。

使用 Notary 签名镜像

Docker 镜像签名依赖于 Notary 服务，其核心流程如下：

1. 开发者构建镜像并推送至 Registry
2. Notary 客户端生成镜像哈希，并使用私钥进行签名
3. 签名信息上传至 Notary 服务器，与镜像元数据关联
4. 用户拉取时自动下载签名并验证公钥链

密钥管理策略

企业应建立分级密钥体系以保障安全性：

密钥类型	用途	存储建议
根密钥 (Root Key)	签发其他密钥	离线保存，HSM 加密
目标密钥 (Target Key)	签署镜像标签	开发人员本地加密存储
时间戳密钥 (Timestamp Key)	防止重放攻击	定期轮换，自动更新

graph TD A[构建镜像] --> B[推送至Registry] B --> C[触发Notary签名] C --> D[生成数字签名] D --> E[存储至Notary服务] E --> F[用户拉取验证] F --> G[校验签名有效性] G --> H[运行可信容器]

第二章：Notary 与 Cosign 签名机制原理剖析

2.1 理解可信镜像签名的必要性与安全模型

在容器化部署日益普及的背景下，确保镜像来源的真实性与完整性成为安全防护的关键环节。未经授权或被篡改的镜像可能导致供应链攻击，造成严重安全隐患。

镜像签名的核心价值

通过数字签名机制，开发者可对镜像进行身份绑定，运行时系统验证签名以确认其未被篡改且来自可信源。

典型安全模型组成

• 私钥签名：发布者使用私钥对镜像摘要进行签名
• 公钥验证：部署环境利用公钥验证签名合法性
• 信任链建立：结合PKI体系形成完整的信任传递路径

cosign sign --key cosign.key registry.example.com/app:v1.2
# 使用cosign工具对指定镜像执行签名操作，
# cosign.key为私钥文件，确保仅授权方能签署

该流程保障了从构建到部署全过程的可验证性，构筑起容器生态中的最小信任基线。

2.2 Notary 架构解析：基于 The Update Framework 的信任链

Notary 是 Docker 开源的镜像签名与验证系统，其核心架构源自 The Update Framework（TUF），通过分层密钥机制构建安全的信任链。

信任层级与角色划分

TUF 定义了多个关键角色，各自承担不同职责：

• Root：根密钥，定义系统信任锚点
• Targets：指定可信任的软件目标及其哈希值
• Snapshot：描述仓库当前状态，防止滚动回放攻击
• Timestamp：标识最新元数据时间，防御冻结攻击

元数据签名流程

{
  "signed": {
    "_type": "targets",
    "version": 1,
    "targets": {
      "app:v1.0": {
        "hashes": {
          "sha256": "a1b2c3..."
        },
        "length": 1024
      }
    }
  },
  "signatures": [
    {
      "keyid": "target-key-1",
      "sig": "abc123..."
    }
  ]
}

该 JSON 片段展示了 Targets 角色如何对镜像版本进行哈希签名。客户端首先验证 Root 签名，逐级校验直至目标镜像，形成完整的信任链传递。

2.3 Cosign 简化签名：基于 Sigstore 的无服务器签名实践

Cosign 是 Sigstore 项目中的核心组件，专为容器镜像和工件提供无缝的无密钥签名与验证能力。它通过集成 Fulcio CA 和 Rekor 可信日志，实现开发者无需管理私钥即可完成可信签名。

签名流程自动化

使用 OpenID Connect（OIDC），Cosign 可在 CI/CD 环境中自动获取短期证书完成签名：

cosign sign --oidc-issuer=https://accounts.google.com \
  --identity-token=$(TOKEN) \
  gcr.io/example/image:tag

该命令通过 OIDC 身份认证向 Fulcio 请求证书，签名后将元数据记录至 Rekor 公共日志，确保可审计性。

关键优势对比

特性	传统 GPG 签名	Cosign + Sigstore
密钥管理	手动维护，易泄露	无密钥，基于 OIDC
审计支持	有限	集成 Rekor，全程可追溯

2.4 公钥私钥体系在镜像签名中的应用详解

镜像签名的基本原理

在容器化环境中，镜像签名用于验证镜像来源的真实性与完整性。公钥私钥体系为此提供了基础支撑：开发者使用私钥对镜像摘要进行签名，分发时附带签名文件；用户则通过对应的公钥验证签名，确保镜像未被篡改。

典型工作流程

1. 构建系统生成镜像并计算其哈希值
2. 使用私钥对哈希值进行数字签名
3. 将镜像、签名及证书一同发布
4. 客户端下载后用公钥验证签名有效性

# 示例：使用cosign对容器镜像签名
cosign sign --key cosign.key registry.example.com/myapp:v1

该命令利用本地私钥（cosign.key）对指定镜像进行签名，签名结果上传至镜像仓库。后续拉取时可通过公钥自动校验。

信任链的建立

角色	持有密钥类型	职责
镜像发布者	私钥	签署镜像摘要
镜像使用者	公钥	验证签名合法性

2.5 签名元数据存储与验证流程深度拆解

元数据结构设计

签名元数据通常包含签名值、时间戳、公钥指纹和哈希算法类型。采用JSON格式存储，便于序列化与网络传输：

{
  "signature": "base64-encoded-value",
  "timestamp": 1717036800,
  "keyFingerprint": "a1b2c3d4",
  "hashAlgorithm": "SHA-256"
}

该结构确保所有验证所需信息集中管理，支持快速解析与校验。

验证流程逻辑

验证过程分为三步：首先解析元数据，其次使用公钥解密签名获取哈希值，最后对比本地计算的哈希值是否一致。

1. 提取原始数据并计算其哈希（如SHA-256）
2. 从元数据中取出签名与公钥，执行RSA-PSS验证算法
3. 比对哈希值，一致则验证通过

此机制保障了数据完整性与来源可信性，防止中间人攻击。

第三章：环境准备与工具部署实战

3.1 安装配置 Docker、Notary Server 与 Trust Server

在构建安全的容器镜像分发体系前，需首先部署核心组件。Docker 是容器运行的基础平台，而 Notary Server 和 Trust Server 则共同实现内容信任机制。

安装 Docker 引擎

大多数 Linux 发行版可通过包管理器安装 Docker：

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

安装后需启动服务并添加用户到 docker 组以避免使用 sudo。

部署 Notary Server

Notary Server 基于 TUF（The Update Framework）实现镜像签名验证。使用 Docker Compose 启动服务：

version: '3'
services:
  notary-server:
    image: theupdateframework/notary-server
    ports:
      - "4443:4443"
    environment:
      - METRICS_PROVIDER=none

该配置暴露 4443 端口用于接收签名请求，禁用指标上报以简化开发环境部署。

Trust Server 配置要点

Trust Server 通常与 Docker Registry 深度集成，通过策略引擎判断镜像是否可信。其核心依赖为根证书和角色密钥，需确保与 Notary 共享信任链。

3.2 部署并验证 Cosign 工具链与 Sigstore 集成环境

在构建可信的软件供应链过程中，部署 Cosign 与 Sigstore 的集成环境是实现容器镜像签名与验证的关键步骤。首先需安装 Cosign 工具链，可通过以下命令获取：

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

该脚本从官方仓库下载适用于 AMD64 架构的 Cosign 二进制文件，赋予可执行权限后移至系统路径，确保全局调用能力。 完成安装后，使用 Sigstore 公共 Federation 模式生成密钥对：

cosign generate-key-pair

执行后将生成 `cosign.key` 和 `cosign.pub`，前者用于签名，后者用于后续验证。 为验证集成有效性，可对本地镜像进行签名并查询其在 Rekor 中的存证记录：

1. 构建并推送容器镜像至镜像仓库
2. 执行 cosign sign --key cosign.key target-image:tag 完成签名
3. 通过 cosign verify --key cosign.pub target-image:tag 验证明细

系统将自动向 Sigstore 的透明日志（Rekor）提交签名记录，确保可审计性与不可否认性。

3.3 创建和管理用于签名的企业级密钥对

在企业级安全架构中，数字签名依赖高强度的非对称密钥对。推荐使用 RSA-2048 或更高级别的算法生成密钥，确保长期安全性。

密钥生成与存储规范

使用 OpenSSL 生成私钥并设置访问权限：

openssl genpkey -algorithm RSA -out enterprise-private-key.pem -pkeyopt rsa_keygen_bits:2048
chmod 600 enterprise-private-key.pem

上述命令创建一个 2048 位的 RSA 私钥，并通过 chmod 600 限制仅所有者可读写，防止未授权访问。

公钥提取与分发流程

从私钥导出公钥，供外部验证签名：

openssl pkey -in enterprise-private-key.pem -pubout -out enterprise-public-key.pem

该命令提取公钥部分，可用于分发给合作伙伴或集成至 API 网关进行请求签名校验。

密钥类型	用途	存储位置
RSA 私钥	签名生成	HSM 或加密密钥库
RSA 公钥	签名验证	公共证书仓库

第四章：企业级 Agent 镜像签名全流程实践

4.1 构建标准化企业 Agent 镜像并推送至私有仓库

在企业级自动化运维中，构建统一的Agent镜像是实现批量管理的基础。通过Dockerfile定义运行环境、依赖库及启动脚本，确保各节点行为一致。

镜像构建流程

• 基于Alpine Linux精简基础镜像，降低安全攻击面
• 集成监控Agent、日志采集模块与配置管理工具
• 使用多阶段构建减少最终镜像体积

FROM alpine:3.18 AS builder
RUN apk add --no-cache curl tar
ADD agent.tar.gz /tmp/
RUN /tmp/install.sh

FROM alpine:3.18
COPY --from=builder /usr/local/bin/agent /usr/local/bin/agent
EXPOSE 9100
HEALTHCHECK --interval=30s CMD agent --check
CMD ["agent", "--daemon"]

上述Dockerfile采用多阶段构建，仅将必要二进制复制到最终镜像。HEALTHCHECK指令用于容器健康检测，CMD定义默认启动命令。

推送至私有仓库

步骤	命令
镜像打标	docker tag agent:v1 registry.corp.com/ops/agent:v1
登录认证	docker login registry.corp.com
推送镜像	docker push registry.corp.com/ops/agent:v1

4.2 使用 Notary 对 Agent 镜像进行内容信任签名

在持续交付流程中，确保 Agent 镜像的完整性和来源可信至关重要。Notary 作为 Docker 内容信任（DCT）的核心组件，通过数字签名机制验证镜像是否由可信方发布且未被篡改。

启用内容信任并签名镜像

首先需设置环境变量以启用 DCT：

export DOCKER_CONTENT_TRUST=1

该变量开启后，所有 docker push 和 pull 操作将自动触发签名验证。推送镜像时，Notary 会使用本地生成的私钥对镜像元数据签名，并将签名信息存储至 Notary 服务端。

信任策略与密钥管理

Notary 采用基于角色的密钥体系，包括：

• 根密钥（Root Key）：初始化信任链，应离线保存；
• 目标密钥（Targets Key）：签署镜像标签；
• 时间戳密钥（Timestamp Key）：防止重放攻击。

通过精细化的密钥控制，团队可实现多级审核与自动化签名流程，显著提升供应链安全性。

4.3 使用 Cosign 实现基于 OIDC 的免密签名与自动化集成

免密签名的核心机制

Cosign 支持通过 OpenID Connect（OIDC）实现无证书的签名操作，开发者无需管理私钥，即可完成容器镜像签名。该机制依赖云提供商的身份令牌（如 Google STS、GitHub Actions ID Token），经 OIDC 验证后临时签发签名权限。

自动化集成配置示例

在 GitHub Actions 中启用 Cosign 免密签名：

- name: Sign image
  uses: sigstore/cosign-github-action/sign@v2
  with:
    registry: ghcr.io
    image: ${{ env.IMAGE_NAME }}
    oidc-issuer: https://token.actions.githubusercontent.com
    identity-token: ${{ secrets.ID_TOKEN }}

上述配置利用 GitHub 提供的 ID_TOKEN 向 Sigstore 发起身份验证，Cosign 自动获取短期签名凭证，确保私钥永不落盘。

• 支持主流云平台和 CI 系统（GitHub Actions、GitLab CI、Tekton）
• 签名记录自动写入 Rekor 公共透明日志
• 结合 Kyverno 可实现集群内策略化验证

4.4 在 CI/CD 流水线中集成签名与策略校验机制

在现代 DevOps 实践中，保障软件交付安全的关键环节之一是在 CI/CD 流水线中引入制品签名与策略校验。通过自动化签名机制，确保镜像或构件来源可信。

签名机制集成

使用 Cosign 对容器镜像进行签名，可在流水线中添加如下步骤：

cosign sign --key cosign.key $IMAGE_DIGEST

该命令基于私钥对镜像摘要签名，确保构建产物完整性。公钥可交由部署环境验证，防止未授权镜像运行。

策略校验执行

借助 Open Policy Agent（OPA），可定义细粒度的准入策略。例如：

1. 镜像必须包含有效签名
2. 基础镜像不得使用 latest 标签
3. 容器不得以 root 权限运行

校验逻辑嵌入 CI 阶段，任何违反策略的提交将被自动拒绝，实现“安全左移”。

第五章：总结与展望

技术演进的持续驱动

现代软件架构正加速向云原生和边缘计算融合。以 Kubernetes 为核心的编排系统已成标准，服务网格（如 Istio）通过透明流量管理提升微服务可观测性。某金融科技公司在日均 20 亿次请求场景下，采用 eBPF 技术实现零侵入式网络监控，延迟下降 38%。

• 使用 eBPF 程序追踪 TCP 连接建立过程
• 结合 Prometheus 实现指标聚合
• 通过 Grafana 动态展示连接异常分布

代码级优化实践

// 基于 sync.Pool 减少 GC 压力
var bufferPool = sync.Pool{
    New: func() interface{} {
        return make([]byte, 4096)
    },
}

func Process(data []byte) []byte {
    buf := bufferPool.Get().([]byte)
    defer bufferPool.Put(buf)
    // 避免频繁内存分配
    return append(buf[:0], data...)
}

未来基础设施趋势

技术方向	当前成熟度	典型应用场景
WASM 边缘运行时	早期采用	CDN 脚本沙箱
AI 驱动的 APM	快速发展	根因分析自动化

src="https://grafana.example.com/d-solo/abc123" width="100%" height="300" frameborder="0">

在大规模分布式系统中，OpenTelemetry 已成为统一遥测数据采集的事实标准。某电商平台通过 OTLP 协议将 traces、metrics、logs 关联，故障定位时间从平均 47 分钟缩短至 9 分钟。