本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

使用 Grafeas 保护软件供应链

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

Kubernetes 已经发展到支持日益复杂的应用程序类别，促成了两个主要的行业趋势：混合云和微服务。随着生产环境复杂性的增加，客户——尤其是企业——要求更好的方式来管理其软件供应链，并对生产部署拥有更集中的可见性和控制。

10月12日，Google 及其合作伙伴宣布推出 Grafeas，这是一项开源计划，旨在为审计和管理现代软件供应链定义最佳实践。借助 Grafeas（希腊语中意为“抄写员”），开发人员可以将 CI/CD 流水线的组件插入到中央真相来源，以跟踪和强制执行策略。Google 还在开发 Kritis（希腊语中意为“法官”），允许 DevOps 团队使用存储在 Grafeas 中的元数据和证明来强制执行部署时镜像策略。

Grafeas 允许构建、审计和合规工具使用中央 API 交换关于容器镜像的全面元数据。这允许强制执行提供对软件供应过程进行中央控制的策略。

应用程序示例：PaymentProcessor

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

由于支付数据的敏感性，开发人员和 DevOps 团队确实希望确保代码满足特定的安全和合规要求，并详细记录代码的出处。有 CI/CD 阶段可以验证 PaymentProcessor 版本的质量，但没有简单的方法可以集中查看/管理此信息

PaymentProcessor 代码的可见性和治理

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

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

假设 PaymentProcessor 容器镜像已创建并推送到 Google Container Registry。本示例使用 gcr.io/exampleApp/PaymentProcessor 容器进行测试。作为 QA 工程师，您希望创建一个证明，证明此镜像可用于生产。我们不信任像 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”AttestationAuthority 备注

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

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

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

kubectl get configmap image-signature-webhook -o yaml

设置准入控制 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 实现。除了基本的准入控制，Kritis 还提供对工作流强制、多权限签名、破窗部署等附加支持。您可以阅读Kritis 白皮书了解更多详情。该团队正在积极开发一个完整的开源实现。我们期待您的反馈！

此外，Kritis 的托管 Alpha 实现，称为 Binary Authorization，已在 Google Container Engine 上可用，并将很快广泛提供。

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

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