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

使用 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 容器进行测试。作为质量保证工程师，您希望创建一个证明此镜像可用于生产环境的证明。我们不再信任像 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 证明的情况下部署镜像

尝试在 paymentProcessor.ymal 中运行镜像，然后再进行 QA 证明

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 证明

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

kubectl apply -f pods/paymentProcessor.yaml

pod "PaymentProcessor" created

添加证明后，将创建 pod，因为满足执行条件。

有关更详细的信息，请参阅此Grafeas 教程。

总结

上面的演示展示了如何将软件供应链与 Grafeas 集成，并获得对生产部署的可见性和控制。但是，演示验证管道本身并不是一个完整的 Kritis 实现。除了基本的准入控制之外，Kritis 还提供对工作流执行、多权限签名、紧急部署等的支持。您可以阅读Kritis 白皮书了解更多详细信息。该团队正在积极致力于完整的开源实现。我们欢迎您的反馈！

此外，Google Container Engine 上提供了 Kritis 的托管 alpha 实现（称为 Binary Authorization），并且很快将提供更广泛的使用。

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

要了解有关 Grafeas 的更多信息并为该项目做出贡献