4. 发布包完整性概念
在云原生网关的交付链路中，发布包（Helm Chart、容器镜像、CRD YAML 集合）从构建到部署会经过多个不可信环境。完整性校验是确保发布包在传输或存储过程中未被篡改、替换或植入后门的第一道防线。本节从软件供应链安全背景出发，梳理完整性校验的数学基础与常见攻击场景。
4.1 软件供应链安全背景
Envoy Gateway 的发布包通常包含二进制 Envoy 代理、控制面组件、RBAC 规则与 CRD 定义。攻击者可能通过以下环节注入恶意内容：
- 构建环境：CI/CD 流水线被攻陷，编译产物被植入后门。
- 制品仓库：镜像仓库或 Chart 仓库被篡改，合法版本被替换为恶意版本。
- 传输链路：中间人攻击修改下载中的 tgz 包或镜像层。
- 本地缓存：开发者或运维机器上的本地缓存被污染。
关键原则：完整性校验必须覆盖 发布包本身 与 发布包元数据（版本号、校验和、签名），且校验过程应在隔离的可信环境中执行。
4.2 完整性校验的数学基础
完整性校验依赖两类核心数学工具：哈希函数 与 数字签名。下表对比了二者的核心特性与在发布包校验中的角色。
| 工具 | 数学基础 | 输出 | 抗篡改能力 | 典型用途 |
|---|---|---|---|---|
| 哈希函数 | 单向压缩映射 | 固定长度摘要（如 SHA-256: 64 字符） | 弱抗碰撞（给定摘要，无法找到另一输入产生相同摘要） | 校验文件是否被修改（防篡改，不防伪造） |
| 数字签名 | 非对称加密 + 哈希 | 签名值（长度取决于算法，如 ECDSA 约 70 字节） | 强抗伪造（无私钥无法生成合法签名） | 验证发布包来源与完整性（防篡改 + 防伪造） |
4.2.1 哈希函数：完整性校验的基石
哈希函数将任意长度的输入数据映射为固定长度的输出（摘要）。对于发布包完整性，常用 SHA-256 或 SHA-512。其核心安全属性包括：
- 抗原像性：给定摘要 h，无法找到输入 m 使得 H(m) = h。
- 抗第二原像性：给定输入 m₁，无法找到另一输入 m₂ 使得 H(m₁) = H(m₂)。
- 抗碰撞性：无法找到任意两个不同的输入 m₁ 与 m₂ 使得 H(m₁) = H(m₂)。
在发布包校验中，哈希值通常以 checksums.txt 或 values.sha256 文件形式随包分发。校验流程如下：
# 下载发布包与校验和文件
wget https://example.com/envoy-gateway-1.0.0.tgz
wget https://example.com/envoy-gateway-1.0.0.tgz.sha256
# 计算本地哈希
sha256sum envoy-gateway-1.0.0.tgz
# 对比：若一致则完整性通过，否则包已被篡改
cat envoy-gateway-1.0.0.tgz.sha256
⚠ 哈希校验的局限：哈希只能检测 无意的损坏 或 被动的篡改。如果攻击者同时替换了发布包 和 校验和文件，哈希校验将完全失效。此时需要数字签名。
4.2.2 数字签名：防伪造的完整性保障
数字签名使用私钥对发布包的哈希值进行加密签名，公钥随包分发或通过 PKI 体系获取。验证方用公钥解密签名并与本地计算的哈希对比。流程如下：
- 签名方：计算发布包哈希 → 使用私钥加密哈希 → 生成签名文件（如
.sig或.asc）。 - 验证方：下载发布包 + 签名文件 + 公钥 → 计算本地哈希 → 使用公钥解密签名 → 对比两个哈希值。
Envoy Gateway 社区通常使用 Cosign（基于 Sigstore 生态）或 GnuPG 对容器镜像与 Helm Chart 进行签名。以下为 Cosign 验证示例：
# 验证容器镜像签名
cosign verify \
--key https://keys.example.com/envoy-gateway.pub \
registry.example.com/envoy-gateway:v1.0.0
# 验证 Helm Chart 签名（使用 GnuPG）
gpg --verify envoy-gateway-1.0.0.tgz.asc envoy-gateway-1.0.0.tgz
4.3 常见的完整性攻击场景
理解攻击场景有助于设计更健壮的校验策略。下表列出三种典型攻击及其对发布包完整性的影响。
| 攻击类型 | 攻击手法 | 绕过方式 | 防御措施 |
|---|---|---|---|
| 中间人篡改 | 在 HTTP/HTTPS 传输中替换包内容 | 若仅使用哈希校验，攻击者可同时替换校验和文件 | 使用 TLS + 数字签名；签名文件通过独立通道分发 |
| 仓库投毒 | 攻击者获得仓库写入权限，上传恶意版本 | 合法版本被覆盖，用户下载恶意包 | 启用仓库级签名验证（如 Notary、Harbor 签名策略） |
| 依赖混淆 | 攻击者注册与内部包同名的公共包，利用包管理器的优先级机制 | 构建工具自动拉取恶意公共包 | 锁定依赖版本 + 校验依赖包的哈希与签名 |
4.4 完整性校验的信任链模型
下图展示了从发布包构建到部署的完整性校验信任链。每个环节的校验结果必须传递到下一环节，形成不可断开的链式验证。
实践建议：在 Envoy Gateway 的发布流程中，建议使用 SLSA（Supply-chain Levels for Software Artifacts） 框架定义完整性等级。至少达到 SLSA Level 2（要求签名 + 隔离构建），推荐 Level 3（要求防篡改构建 + 可验证的 provenance）。
4.5 完整性校验在 Envoy Gateway 中的落地
Envoy Gateway 社区已采用以下完整性校验实践：
- 容器镜像：使用 Cosign 对每个 release 镜像进行签名，签名存储在 OCI 仓库的
.sig标签中。 - Helm Chart：使用 GnuPG 对 Chart 包进行签名，签名文件随 Chart 上传至 Chart 仓库。
- CRD YAML：在发布包的
checksums.txt中记录每个 YAML 文件的 SHA-256 值，并由发布者使用私钥对整个校验和文件签名。
以下为 Envoy Gateway 发布包完整性校验的完整命令示例：
# 1. 下载发布包与签名
helm pull oci://registry.example.com/charts/envoy-gateway --version 1.0.0
cosign download signature registry.example.com/envoy-gateway:v1.0.0
# 2. 验证容器镜像签名
cosign verify \
--key https://keys.example.com/envoy-gateway.pub \
registry.example.com/envoy-gateway:v1.0.0
# 3. 验证 Helm Chart 签名
gpg --verify envoy-gateway-1.0.0.tgz.asc envoy-gateway-1.0.0.tgz
# 4. 验证 CRD 文件完整性
sha256sum --check checksums.txt
gpg --verify checksums.txt.asc checksums.txt
⚠ 常见陷阱：不要仅依赖
helm verify 命令，该命令只校验 Chart 本身的签名，不校验 Chart 中引用的容器镜像签名。必须分别对镜像和 Chart 执行独立的完整性校验。