本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

使用 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 併為專案做出貢獻