本文发布时间超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已不正确。

使用 Grafeas 保护软件供应链

作者：Kelsey Hightower (Google)，Sandra Guo (Google) |

Kubernetes 已经发展到支持越来越复杂的应用类别，从而推动了两个主要行业趋势的发展：混合云和微服务。随着生产环境复杂性的增加，客户（尤其是企业）正在寻求更好的方式来管理其软件供应链，并对生产部署拥有更集中的可见性和控制能力。

10 月 12 日，Google 与合作伙伴共同宣布推出 Grafeas，这是一项开源计划，旨在为审计和管理现代软件供应链定义最佳实践。通过 Grafeas（希腊语意为“记录员”），开发者可以将 CI/CD 流水线的组件接入一个中心化的真相来源，用于跟踪和执行策略。Google 还在开发 Kritis（希腊语意为“法官”），允许开发运维团队使用存储在 Grafeas 中的元数据和证明来强制执行部署时镜像策略。

Grafeas 允许构建、审计和合规工具使用中心化 API 交换容器镜像的全面元数据。这使得能够强制执行策略，从而对软件供应过程进行集中控制。

应用示例：PaymentProcessor

让我们考虑一个简单的应用，PaymentProcessor，它从数据库中检索、处理和更新支付信息。该应用由两个容器组成：一个标准的 Ruby 容器和自定义逻辑。

由于支付数据的敏感性，开发者和开发运维团队非常希望确保代码符合特定的安全和合规要求，并详细记录代码的来源。尽管 CI/CD 阶段会验证 PaymentProcessor 版本的质量，但没有一个简单的方法来集中查看/管理这些信息

PaymentProcessor 代码的可见性和治理

Grafeas 提供了一个 API，供客户集中管理各种 CI/CD 组件创建的元数据，并通过 Kritis 实现来启用部署时策略强制执行。

让我们考虑一个基本示例，说明 Grafeas 如何使用演示验证流水线为 PaymentProcessor 应用提供部署时控制。

假设 PaymentProcessor 容器镜像已创建并推送到 Google Container Registry。此示例使用 gcr.io/exampleApp/PaymentProcessor 容器进行测试。作为质量保证工程师，你希望创建一个证明来认证此镜像用于生产环境。与其信任一个可能被重用并稍后指向不同容器镜像的镜像标签（如 0.0.1），我们可以信任镜像摘要以确保证明链接到完整的镜像内容。

1. 设置环境

生成签名密钥

gpg --quick-generate-key --yes qa\_bob@example.com

导出镜像签名者的公钥

gpg --armor --export image.signer@example.com \> ${GPG\_KEY\_ID}.pub

通过 Grafeas API 创建“qa”证明机构备注

curl -X POST \  
  "http://127.0.0.1:8080/v1alpha1/projects/image-signing/notes?noteId=qa" \  
  -d @note.json

为 Admission 控制创建 Kubernetes ConfigMap 并存储 QA 签名者的公钥

kubectl create configmap image-signature-webhook \  
  --from-file ${GPG\_KEY\_ID}.pub

kubectl get configmap image-signature-webhook -o yaml

设置一个 Admission 控制 webhook，要求在部署期间提供 QA 签名。

kubectl apply -f kubernetes/image-signature-webhook.yaml

2. 尝试部署没有 QA 证明的镜像

在镜像获得 QA 证明之前，尝试运行 paymentProcessor.yaml 中的镜像

kubectl apply -f pods/nginx.yaml

apiVersion: v1

kind: Pod

metadata:

  name: payment

spec:

  containers:

    - name: payment

      image: "gcr.io/hightowerlabs/payment@sha256:aba48d60ba4410ec921f9d2e8169236c57660d121f9430dc9758d754eec8f887"

创建 paymentProcessor Pod

kubectl apply -f pods/paymentProcessor.yaml

注意 paymentProcessor Pod 未创建，并返回以下错误

The  "" is invalid: : No matched signatures for container image: gcr.io/hightowerlabs/payment@sha256:aba48d60ba4410ec921f9d2e8169236c57660d121f9430dc9758d754eec8f887

3. 创建镜像签名

假设镜像摘要存储在 Image-digest.txt 中，对镜像摘要进行签名

gpg -u qa\_bob@example.com \  
  --armor \  
  --clearsign \  
  --output=signature.gpg \  
  Image-digest.txt

4. 将签名上传到 Grafeas API

从签名生成 pgpSignedAttestation 事件

cat \> occurrence.json \<\<EOF  
{  
  "resourceUrl": "$(cat image-digest.txt)",  
  "noteName": "projects/image-signing/notes/qa",  
  "attestation": {  
    "pgpSignedAttestation": {  
       "signature": "$(cat signature.gpg)",  
       "contentType": "application/vnd.gcr.image.url.v1",  
       "pgpKeyId": "${GPG\_KEY\_ID}"  
    }  
  }  
}  
EOF

通过 Grafeas API 上传证明

curl -X POST \  
  'http://127.0.0.1:8080/v1alpha1/projects/image-signing/occurrences' \  
  -d @occurrence.json

5. 在生产部署期间验证 QA 证明

现在镜像在 Grafeas API 中拥有正确的证明，尝试运行 paymentProcessor.yaml 中的镜像

kubectl apply -f pods/paymentProcessor.yaml

pod "PaymentProcessor" created

添加证明后，Pod 将会被创建，因为执行条件已满足。

更多详细信息，请参阅此 Grafeas 教程。

总结

上面的演示展示了如何将你的软件供应链与 Grafeas 集成，并对生产部署获得可见性和控制。然而，演示验证流水线本身并不是一个完整的 Kritis 实现。除了基本的 Admission 控制，Kritis 还提供了对工作流强制执行、多机构签名、紧急部署等更多的支持。你可以阅读 Kritis 白皮书了解更多详情。团队正在积极开发完整的开源实现。我们非常欢迎你的反馈！

此外，一个托管的 Kritis Alpha 实现，称为 Binary Authorization（二进制授权），已在 Google Container Engine 上可用，并将很快面向更广泛的用户提供。

Google、JFrog 和其他合作伙伴基于我们为内部和企业客户构建安全、大型和复杂微服务部署的共同经验，联合创建了 Grafeas。Grafeas 是一项全行业的社区努力。

了解更多关于 Grafeas 并为项目做贡献