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

使用 Grafeas 保護軟體供應鏈

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

Kubernetes 已發展為支援日益複雜的應用程式類別，從而推動了兩個主要的產業趨勢：混合雲和微服務。隨著生產環境中複雜性的增加，客戶 (尤其是企業) 要求更好的方法來管理其軟體供應鏈，並對生產部署進行更集中的可見性和控制。

在 10 月 12 日，Google 和合作夥伴宣布 Grafeas，這是一個開放原始碼倡議，旨在定義稽核和管理現代軟體供應鏈的最佳實務。透過 Grafeas (希臘語中的「scribe」)，開發人員可以將 CI/CD 管道的元件插入到單一事實來源中，以追蹤和實施政策。Google 也在開發 Kritis (希臘語中的「judge」)，允許開發維運團隊使用儲存在 Grafeas 中的中繼資料和證明來實施部署時映像檔政策。

Grafeas 允許建置、稽核和合規性工具使用中央 API 交換容器映像檔上的全面中繼資料。這允許實施策略，以提供對軟體供應流程的集中控制。

範例應用程式：PaymentProcessor

讓我們考慮一個簡單的應用程式 PaymentProcessor，它會擷取、處理和更新儲存在資料庫中的付款資訊。此應用程式由兩個容器組成：一個標準 ruby 容器和自訂邏輯。

由於付款資料的敏感性，開發人員和開發維運團隊確實希望確保程式碼符合某些安全性和合規性要求，並提供有關此程式碼出處的詳細記錄。存在驗證 PaymentProcessor 版本品質的 CI/CD 階段，但沒有簡單的方法可以集中檢視/管理此資訊

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 證明的映像檔

在 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 證明

現在映像檔在 Grafeas API 中具有正確的證明，嘗試在 paymentProcessor.ymal 中執行映像檔

kubectl apply -f pods/paymentProcessor.yaml

pod "PaymentProcessor" created

新增證明後，將會建立 Pod，因為符合執行條件。

如需更多詳細資訊，請參閱此 Grafeas 教學課程。

摘要

上述示範展示了如何將您的軟體供應鏈與 Grafeas 整合，並獲得對生產部署的可見性和控制。但是，示範驗證管道本身並不是完整的 Kritis 實作。除了基本許可控制之外，Kritis 還為工作流程實施、多授權簽署、breakglass 部署等提供額外支援。您可以閱讀 Kritis 白皮書 以取得更多詳細資訊。團隊正在積極開發完整的開放原始碼實作。我們很樂意收到您的意見反應！

此外，在 Google Container Engine 上提供名為 Binary Authorization 的 Kritis 託管 Alpha 實作，並且很快將可供更廣泛使用。

Google、JFrog 和其他合作夥伴根據我們為內部和企業客戶建置安全、大型且複雜的微服務部署的共同經驗，共同創建了 Grafeas。Grafeas 是一項產業範圍的社群努力。

若要深入瞭解 Grafeas 並為專案做出貢獻