nebinfra/trust
GitHub: nebinfra/trust
NebInfra 的公钥仓库，提供容器镜像和二进制制品的供应链签名验证与透明度审计能力。
Stars: 1 | Forks: 0
# NebInfra Trust
**NebInfra 生产版本发布的公钥与供应链透明度。**
本仓库是 NebInfra 发布到生产环境的每个容器镜像和二进制文件的信任锚点。此处的密钥允许任何第三方（运维人员、客户、审计人员、下游集成商）独立验证制品是否：
1. 由 NebInfra 的标准 CI/CD 流水线从官方源代码仓库构建。
2. 由私钥仅存放在 AWS KMS 中的密钥签名。
3. 在 Sigstore Rekor 透明度日志中拥有公开可审计的签名记录。
如果这三项检查中有任何一项失败，则该制品是不真实的，不得运行。
## 目录
- [信任信号一览](#trust-signals-at-a-glance)
- [已签名的应用程序](#signed-applications)
- [快速入门：验证发布版本](#quick-start-verify-a-release)
- [验证方案](#verification-recipes)
- [容器镜像](#container-images)
- [二进制发布制品](#binary-release-artifacts)
- [SLSA 来源证明](#slsa-provenance-attestations)
- [SBOM 证明](#sbom-attestations)
- [面向严格验证者的 Pinning](#pinning-for-strict-verifiers)
- [密钥轮换生命周期](#key-rotation-lifecycle)
- [透明度日志 (Rekor)](#transparency-log-rekor)
- [架构与威胁模型](#architecture-and-threat-model)
- [报告问题](#reporting-concerns)
## 信任信号一览
| 属性 | 实现方式 |
| --- | --- |
| 签名方案 | 使用 AWS KMS 支持的 **ECDSA P-256** 客户主密钥的 [Sigstore cosign](https://docs.sigstore.dev/cosign/overview/) |
| 密钥保管 | 私钥永远不会离开 AWS KMS。签名通过 KMS API 执行，且仅在生产 CI 环境中通过稳定的别名（`alias/cosign--prod`）进行 |
| 透明度 | 每个生产签名都会发布到公开的 [Sigstore Rekor](https://rekor.sigstore.dev) 透明度日志中 |
| 来源 | 每个容器镜像都会记录 SLSA 风格的来源证明，将制品与其源代码仓库、commit SHA 以及构建它的 GitHub Actions 工作流绑定 |
| SBOM | 每个容器镜像都会记录 SPDX-JSON 格式的 SBOM 证明 |
| 轮换 | 每季度在 1 月 1 日、4 月 1 日、7 月 1 日和 10 月 1 日 UTC 时间 00:00 自动轮换。旧的公钥仍可用于验证历史发布版本 |
| 持续审计 | 每个 `nebinfra/` 仓库每周运行一次 Rekor 扫描，如果发现任何无法追溯到合法 CI 运行的签名，将呼叫待命人员 |
## 已签名的应用程序
| 应用程序 | 描述 | 源代码仓库 | 活动公钥 |
| --- | --- | --- | --- |
| `nebguard` | NebCore 护栏引擎 | [nebinfra/nebguard](https://github.com/nebinfra/nebguard) | [`cosign-keys/nebguard-prod.pub`](cosign-keys/nebguard-prod.pub) |
| `nebcli` | NebCore 平台 CLI | [nebinfra/nebcli](https://github.com/nebinfra/nebcli) | [`cosign-keys/nebcli-prod.pub`](cosign-keys/nebcli-prod.pub) |
| `nebcore-ai` | NebCore AI 运行时 | [nebinfra/nebcore-ai](https://github.com/nebinfra/nebcore-ai) | [`cosign-keys/nebcore-ai-prod.pub`](cosign-keys/nebcore-ai-prod.pub) |
| `nebcore-operator` | NebCore Kubernetes operator | [nebinfra/nebcore-operator](https://github.com/nebinfra/nebcore-operator) | [`cosign-keys/nebcore-operator-prod.pub`](cosign-keys/nebcore-operator-prod.pub) |
| `platform-backend` | NebInfra 平台 API 后端 | [nebinfra/platform-backend](https://github.com/nebinfra/platform-backend) | [`cosign-keys/platform-backend-prod.pub`](cosign-keys/platform-backend-prod.pub) |
轮换后，先前的公钥将保留在 `cosign-keys/archive/-prod-.pub` 中，以便旧版本仍可验证。请参阅 [密钥轮换生命周期](#key-rotation-lifecycle)。
## 快速入门：验证发布版本
您需要安装 [`cosign`](https://docs.sigstore.dev/cosign/installation/)（推荐使用 v2 版本）。
```
APP=nebguard
DIGEST=sha256: # from your image registry, e.g. `crane digest `
IMAGE=380277571885.dkr.ecr.us-east-2.amazonaws.com/${APP}@${DIGEST}
cosign verify \
--key https://raw.githubusercontent.com/nebinfra/trust/main/cosign-keys/${APP}-prod.pub \
--rekor-url https://rekor.sigstore.dev \
"${IMAGE}"
```
成功运行将打印出 JSON 编码的验证记录。任何非零退出码或除该记录之外的任何输出都表示验证失败，因此**切勿运行该制品**。
## 验证方案
### 容器镜像
```
cosign verify \
--key https://raw.githubusercontent.com/nebinfra/trust/main/cosign-keys/-prod.pub \
--rekor-url https://rekor.sigstore.dev \
@sha256:
```
始终通过 digest 而不是 tag 来引用镜像。Tag 是可变的；而 digest 不是。
### 二进制发布制品
```
gh release download v1.2.3 --pattern '*Linux_arm64*' --repo nebinfra/
cosign verify-blob \
--key https://raw.githubusercontent.com/nebinfra/trust/main/cosign-keys/-prod.pub \
--rekor-url https://rekor.sigstore.dev \
--signature .sig \
```
每个发布制品都会在同一个 GitHub Release 中附带一个同级的 `.sig` 文件。
### SLSA 来源证明
```
cosign verify-attestation \
--key https://raw.githubusercontent.com/nebinfra/trust/main/cosign-keys/-prod.pub \
--rekor-url https://rekor.sigstore.dev \
--type slsaprovenance \
@sha256: | jq '.payload | @base64d | fromjson'
```
解码后的 payload 会公开以下信息：
- `buildType: https://github.com/actions/runner/workflows@v1`：证明构建是在 GitHub Actions 上运行的。
- `invocation.configSource.uri: git+https://github.com/nebinfra/@refs/heads/main`：证明构建源自标准 NebInfra 仓库的 `main` 分支。
- `invocation.configSource.digest.sha1`：锁定生成该制品的确切源 commit。
严格的验证者在信任镜像之前，应断言这三个值是否符合预期。其中任何一项不匹配都表明存在伪造签名或基于非标准源代码的构建运行。
### SBOM 证明
```
cosign verify-attestation \
--key https://raw.githubusercontent.com/nebinfra/trust/main/cosign-keys/-prod.pub \
--rekor-url https://rekor.sigstore.dev \
--type spdxjson \
@sha256: | jq '.payload | @base64d | fromjson'
```
SBOM 采用 SPDX 2.3 JSON 格式，并描述了已发布的准确字节。将已验证的 payload 通过管道传递给 `grype` 或 `trivy sbom` 即可进行漏洞扫描，而无需重新拉取镜像。
## 面向严格验证者的 Pinning
通过 `https://raw.githubusercontent.com/nebinfra/trust/main/...` 拉取公钥意味着信任当前位于 `main` 分支上的任何内容。如果仓库被接管，伪造的密钥就可能被替换进来。严格的验证者应将 URL 锁定到特定的 git commit SHA：
```
cosign verify \
--key https://raw.githubusercontent.com/nebinfra/trust//cosign-keys/-prod.pub \
--rekor-url https://rekor.sigstore.dev \
@sha256:
```
解析一次 SHA 并将其嵌入到您的验证策略中：
```
git ls-remote https://github.com/nebinfra/trust main | awk '{print $1}'
```
仅当通过本仓库的 GitHub Releases 宣布合法的密钥轮换时，才重新进行锁定。
## 密钥轮换生命周期
| 步骤 | 操作 |
| --- | --- |
| **计划时间** | 1 月 1 日、4 月 1 日、7 月 1 日、10 月 1 日 UTC 时间 00:00 |
| **驱动程序** | `shared-actions/cosign-key-rotate.yml@v1` 可复用 GitHub Actions 工作流 |
| **新密钥** | 在 AWS KMS 中创建一个新的 ECDSA P-256 客户主密钥 |
| **别名切换** | 将稳定别名 `alias/cosign--prod` 重新指向新的 CMK，以便生产 CI 立即使用新密钥，而无需更改代码 |
| **归档** | 先前的公钥将被移动到 `cosign-keys/archive/-prod-.pub` |
| **激活** | 新公钥作为 `cosign-keys/-prod.pub` 提交 |
| **停用** | 旧的 CMK 将在 AWS KMS 中被计划删除，并设有 30 天的可恢复窗口 |
要验证使用先前密钥签名的制品，请将 `--key` 指向归档文件：
```
cosign verify \
--key https://raw.githubusercontent.com/nebinfra/trust/main/cosign-keys/archive/-prod-.pub \
--rekor-url https://rekor.sigstore.dev \
@sha256:
```
## 透明度日志 (Rekor)
每个 NebInfra 生产签名都会上传到 的公开 Sigstore Rekor 透明度日志中。这提供了单纯签名无法提供的三项保证：
- **经过验证的时间戳。** 签名在时间上被锚定。验证者可以拒绝在预期发布窗口之外签发的签名，从而挫败伪造日期的伪造品。
- **公开可审计性。** 任何人（包括您）都可以在 Rekor 中查询 NebInfra 公钥下的所有条目。无法追溯到合法 CI 运行的条目即构成密钥滥用的证据。
- **持续监控。** 每个 `nebinfra/` 仓库每周运行一次 `rekor-audit.yml` 定时任务，将 Rekor 条目与成功的生产 CI 运行记录进行比较，一旦发现任何孤儿条目即呼叫待命人员。
## 架构与威胁模型
完整设计（KMS 拓扑、CI/CD 签名流程、威胁模型和事件响应手册）保存在 NebInfra 的内部架构文档中。上述验证方案是独立的；验证制品无需任何内部文档。
## 报告问题
如果您怀疑密钥泄露、发现恶意的 Rekor 条目、供应链异常，或对 NebInfra 发布版本的完整性有任何其他疑虑，请在相关的 `nebinfra/` 仓库中发起一个**安全公告**（security advisory）：
对于非敏感报告，公开的 issue 也是可以接受的。供应链报告将被视为最高优先级，并直接转交给 NebInfra 的安全值班人员。
标签：CVE, DevSecOps, Sigstore, SLSA规范, Web截图, 上游代理, 基础设施, 容器安全, 数字签名, 请求拦截, 软件供应链安全, 远程方法调用