Binary Authorization 與成品安全性

供應鏈安全性簡介

隨著組織轉向容器化工作負載，保護軟體供應鏈變得至關重要。僅保護執行環境是不夠的；您還必須確保僅允許受信任、經過驗證的程式碼執行。

Binary Authorization 與 Artifact Registry 協同運作，為您在 GKE 與 Cloud Run 中的容器部署提供強大的防禦深度策略。

白話文解釋（Plain English Explanation）

比喻 1：夜店門口拿賓客名單的保鑣

把 Binary Authorization 想成站在 GKE 叢集門口的嚴格保鑣。容器映像檔就是想進場的客人，Attestor（認證者） 是保鑣手上的賓客名單——只有被信任的審核者（資安團隊、CI pipeline、QA leader）簽核過名字（映像檔 digest）的客人才能進場。Attestation（認證） 本身就是手環：一個由 Cloud KMS 簽出的密碼學簽章，證明這個映像檔通過了某一道關卡。沒有手環就不能進去——即使昨天剛跑過也一樣。Continuous Validation（持續驗證） 就是保鑣每小時再巡一遍，確認沒人偷偷從後門溜進來。

比喻 2：機場海關

Artifact Registry 的弱點掃描 像是機場海關。每個抵達的容器（行李）都會被 X 光掃描已知威脅（OSV 資料庫中的 CVE）。自動掃描在 push 時觸發（入境申報），持續分析則會隨著新的威脅情報出爐而反覆重掃倉庫裡的舊行李——下週才公布、針對你今天就推上去的 base layer 的 CVE，會回溯顯示出來。Remote Repositories（遠端儲存庫） 像是免稅轉機區：外部映像檔（Docker Hub）會先被 Google Cloud 快取並掃描，你的 production 工作負載永遠不會直接暴露在公開網際網路上。

比喻 3：公證人與國際認證章

cosign + Sigstore 簽章流程就像把文件拿去公證以便國際使用。開發者用私鑰簽章（cosign sign），公證人的印章（簽章作為 OCI artifact 存在映像檔旁邊）證明簽章當下文件為真，Binary Authorization 則是拒絕接受任何沒有蓋章文件的外國大使館。Dry-run 模式就是彩排：大使館記錄每一份它會拒絕的文件，但全部都先放行，這樣你就能在正式強制前先稽核一遍。

Artifact Registry：從源頭強化安全性

Artifact Registry 是 Container Registry 的進階版本，提供了一個安全的位置來儲存與管理您的建置成品 (Build Artifacts)。

1. 弱點掃描 (Vulnerability Scanning)

• 自動掃描： 每當推送映像檔時，Artifact Registry 都會掃描其是否存在已知的弱點 (CVEs)。
• 隨選掃描 (On-demand)： 允許您在推送之前掃描本地映像檔，或掃描登錄檔中現有的映像檔。
• 持續分析： 監控在映像檔儲存之後才被發現的新弱點。

2. IAM 與強化措施

• 儲存庫隔離： 為不同的團隊或環境（開發/生產）建立獨立的儲存庫。
• 清理政策： 自動刪除舊的或有弱點的映像檔，以縮小攻擊面。
• VPC-SC 整合： 確保僅能從受信任的網路內推送或拉取映像檔。

Binary Authorization：強制執行信任

Binary Authorization 是一項部署時的安全控制措施，確保僅有受信任的容器映像檔能被部署到 Google Kubernetes Engine (GKE) 或 Cloud Run。

運作方式：

1. 政策 (Policy)： 您定義一項政策，指定部署的要求（例如：「全部允許」、「全部拒絕」或「需要認證」）。
2. 認證者 (Attestors)： 一個實體（如建置系統或安全掃描器），負責為映像檔「背書」。
3. 認證 (Attestations)： 由認證者建立的數位簽章，證明映像檔已符合特定標準（例如：已通過弱點掃描）。
4. 強制執行 (Enforcement)： 當發起部署請求時，Binary Authorization 會根據政策檢查映像檔。如果未滿足要求（缺乏簽章），部署將被攔截。

認證工作流程

1. 建置： Cloud Build 建置容器映像檔並將其推送到 Artifact Registry。
2. 掃描： Artifact Registry 進行弱點掃描。
3. 簽署： 如果掃描結果乾淨，Kritis Signer 或自訂腳本會使用 Cloud KMS 建立認證。
4. 驗證： Binary Authorization 根據儲存在認證者中的公開金鑰驗證該簽章。

進階安全模式

1. 緊急規避程序 (Break-glass)

在緊急情況下（例如：關鍵的生產環境修補），您可能需要繞過 Binary Authorization。

• Break-glass： GKE 部署清單中的特殊註解，允許映像檔無視政策違規而執行。
• 稽核： 每次 Break-glass 事件都會記錄在 Cloud Audit Logs 中，以便立即審查與說明理由。

2. SLSA (軟體成品供應鏈層級)

SLSA 是一個旨在防止篡改並提高完整性的安全性框架。

• Google Cloud 服務（如 Cloud Build）提供「建置來源 (Build Provenance)」，透過證明映像檔的建置位置與方式，協助您達到更高的 SLSA 等級。

3. 遠端儲存庫與快取

Artifact Registry 支援遠端儲存庫 (Remote Repositories)（例如：快取 Docker Hub）。

• 安全性： 這允許您對外部映像檔應用弱點掃描，並在外部登錄檔離線時確保可用性。

稽核與監控

• 部署違規： 記錄在 Binary Authorization 稽核記錄中。
• 試執行模式 (Dry Run)： 允許您測試政策而不實際封鎖部署，協助識別哪些部署「將會」被封鎖。

Attestor、KMS 金鑰與已簽署的 Payload

Binary Authorization 的 Attestor（認證者） 是一個 Google Cloud 資源，包含三樣東西：一個 Container Analysis Note（被認證的對象，例如 projects/my-proj/notes/vuln-scan-passed）、一把用來驗證簽章的 PKIX 公鑰，以及一份 IAM 允許清單，規定哪些服務帳號可以對它建立認證。私鑰那一半放在 Cloud KMS 中的非對稱簽章金鑰下（演算法為 EC_SIGN_P256_SHA256 或 RSA_SIGN_PKCS1_4096_SHA512）。

已簽署 Payload 的格式

被簽章的 payload 並不是映像檔的位元組。它是 gcloud container binauthz create-signature-payload 產出的一個小型 JSON blob，內含完整限定的映像檔 digest（gcr.io/proj/app@sha256:abcd…）。這點至關重要，因為：

• 繞過 tag 可變性的問題——簽章綁定的是不可變的 digest，重新 push :latest 並不會繼承信任。
• payload 本身可由任何持有公鑰的人離線重新驗證。
• Cloud KMS 執行實際的 AsymmetricSign 操作，私鑰永遠不離開 HSM。

建立流程範例

gcloud container binauthz create-signature-payload \
  --artifact-url="us-docker.pkg.dev/proj/repo/app@sha256:..." > payload.json

gcloud kms asymmetric-sign \
  --location=global --keyring=binauthz --key=prod-attestor \
  --version=1 --digest-algorithm=sha256 \
  --input-file=payload.json --signature-file=signature.bin

gcloud container binauthz attestations create \
  --artifact-url="us-docker.pkg.dev/proj/repo/app@sha256:..." \
  --attestor=projects/proj/attestors/prod-vuln-scan \
  --signature-file=signature.bin --pgp-key-fingerprint=...

Continuous Validation 與 Dry-Run 模式

Continuous Validation（CV，持續驗證） 是 Binary Authorization 中經常被忽略的另一半。准入控制只在「部署時」檢查映像檔——但 Pod 可能跑上好幾週，而政策也可能在事後被收緊。CV 會週期性地針對每個啟用 Binary Authorization 的 GKE 叢集中所有執行中的 Pod 重新評估「當下」政策，並在執行中的工作負載不再滿足政策時，發送一筆 Cloud Logging 紀錄到 binaryauthorization.googleapis.com%2Fcontinuous_validation 記錄。CV 大約每 24 小時跑一次，且不會驅逐 Pod——它是純觀測，讓 SRE 團隊有時間補救而不會被意外重啟驚到。

Dry-run 作為安全的推行模式

在叢集專屬規則或預設規則上設定 enforcementMode: DRYRUN_AUDIT_LOG_ONLY 會讓 Binary Authorization：

• 依政策評估，宛如真的在強制執行。
• 將每一筆「會被拒絕」事件記錄到 binaryauthorization.googleapis.com%2Factivity，附上 verdict: VIOLATES_POLICY。
• 仍然允許 Pod 通過。

這是把 Attestor 要求導入已有上百個工作負載的叢集時，唯一安全的方式。搭配以 protoPayload.resourceName 分組的 Log Analytics 查詢，可以在切換到 ENFORCED_BLOCK_AND_AUDIT_LOG 之前先列出哪些部署會壞掉。

Cosign、Sigstore 與 Keyless 簽章

雖然 Binary Authorization 原生的 Attestor 格式是 Google Cloud 的標準流程，但 cosign（Sigstore 專案的一部分）已成為開源容器簽章的事實標準，並在 2023 年新增 Sigstore Signature Format 支援後，與 Binary Authorization 完全互通。

三個值得記的 cosign 模式

• 以金鑰簽章： cosign sign --key gcpkms://projects/p/locations/global/keyRings/r/cryptoKeys/k/cryptoKeyVersions/1 IMAGE——使用 Cloud KMS 後端金鑰簽章。簽章會以 OCI artifact（sha256-...sig）的形式存放在 Artifact Registry 中該映像檔旁邊。
• Keyless 簽章（OIDC）： 從 Cloud Build 內執行 cosign sign IMAGE，會用建置的 workload identity OIDC token 向 Sigstore 的 Fulcio CA 換取短期憑證，並把簽章記錄到公開的 Rekor 透明度日誌。沒有需要輪替的長期金鑰。
• 附 predicate 的 attestation： cosign attest --predicate sbom.spdx.json --type spdxjson IMAGE 附上一份結構化的 in-toto attestation（例如 SBOM 或 SLSA 來源證明文件），以相同方式簽章與驗證。

把 cosign 接到 Binary Authorization

將 Binary Authorization Attestor 設定為使用與 cosign 相同的公鑰（cosign public-key --key gcpkms://...），Binary Authorization 就會在准入時接受 cosign 產出的簽章。團隊就能用同一套簽章工具橫跨 GKE、Cloud Run、地端 Kubernetes 與寄存在 ECR 的多雲映像檔。

PSE 考試情境

情境 1：防止部署有弱點的映像檔

「一家公司希望確保任何具有『嚴重 (Critical)』或『高 (High)』弱點分數的容器映像檔，都絕不會被部署到其生產環境 GKE 叢集。您該如何實作？」 解答： 1. 在 Artifact Registry 中啟用弱點掃描。 2. 使用 Cloud Build 觸發掃描。 3. 使用自動簽署工具（如 Kritis），僅在未發現高/嚴重 CVE 時建立認證 (Attestation)。 4. 配置 Binary Authorization 政策，要求生產環境叢集必須具備該特定認證者的簽章。

情境 2：緊急修補

「生產環境發現一個嚴重錯誤。修補程式已就緒，但安全掃描器目前故障，導致無法產生認證。工程師該如何部署修補程式？」 解答： 使用 Break-glass 程序，在 Pod 規格中加入 image-policy.k8s.io/break-glass: "true" 註解。確保事後對該事件進行稽核並說明理由。

總結檢查表

• 描述 Artifact Registry 與 Binary Authorization 之間的關係。
• 解釋認證 (Attestation) 是如何建立與驗證的。
• 識別 Cloud KMS 在簽署過程中的角色。
• 對比「強制執行 (Enforce)」模式與「試執行 (Dry Run)」模式。
• 解釋「緊急規備 (Break-glass)」部署的目的。
• 定義 SLSA 在供應鏈安全性中的重要性。