正在加载…
未找到任何结果。

Apply your skills in Google Cloud console

实验设置说明和要求
保护您的账号和进度。请务必在无痕浏览器窗口中，使用实验凭证运行此实验。

使用二進位授權控管部署作業

实验 35 分钟 universal_currency_alt 5 积分 show_chart 中级
info 此实验可能会提供 AI 工具来支持您学习。
此内容尚未针对移动设备进行优化。
为获得最佳体验，请在桌面设备上访问通过电子邮件发送的链接。

GSP1183

Google Cloud 自修研究室

總覽

二進位授權是部署作業期間的安全性控管機制，可確保只有受信任的容器映像檔能部署至 Google Kubernetes Engine (GKE) 或 Cloud Run。使用二進位授權後，您就能要求受信任的單位在開發過程中簽署映像檔，然後在部署時強制執行簽章驗證程序。透過強制執行驗證程序，您可以確保僅將已通過驗證的映像檔整合至建構與發布的流程，更嚴謹控管容器環境。

下圖顯示二進位授權/Cloud Build 設定中的元件：

Cloud Build 二進位授權驗證管道。建立二進位授權驗證的 Cloud Build 管道。

在這個管道中：

  1. 建構容器映像檔的程式碼會推送至來源存放區，例如 Cloud Source Repositories。
  2. 持續整合 (CI) 工具 Cloud Build 會建構及測試容器。
  3. 建構作業會將容器映像檔推送至 Container Registry 或其他儲存建構映像檔的登錄檔。
  4. Cloud Key Management Service 會為加密編譯金鑰組提供金鑰管理服務，並簽署容器映像檔。產生的簽章會儲存在新建立的驗證中。
  5. 部署時，驗證者會使用金鑰組的公開金鑰確認驗證。二進位授權會強制執行政策，要求提供已簽署的驗證，才能部署容器映像檔。

在本實驗室中，您將瞭解如何運用工具和技術，確保部署的構件安全無虞。本實驗室將著重在建立好但尚未部署至任何特定環境的構件 (容器)。

課程內容

  • 映像檔簽署
  • 許可控制政策
  • 簽署掃描的映像檔
  • 授權已簽署的映像檔
  • 封鎖未簽署的映像檔

設定和需求

實驗室活動開跑須知

請詳閱以下操作說明。實驗室活動會計時，中途無法暫停。點選「Start Lab」後就會開始計時，顯示可使用 Google Cloud 資源的時間。

您將在真正雲端環境中完成實作，而不是在模擬或示範環境。因此，我們會提供新的臨時憑證，讓您在實驗室活動期間登入及存取 Google Cloud。

如要順利完成這個實驗室活動，請先確認：

  • 可以使用標準的網路瀏覽器 (Chrome 瀏覽器為佳)。
注意：請使用無痕模式或私密瀏覽視窗執行本實驗室，防止個人帳戶和學生帳戶之間的衝突，避免個人帳戶產生額外費用。
  • 該來完成實驗室活動了！別忘了，活動開始後就無法暫停。
注意：如果您擁有個人 Google Cloud 帳戶或專案，請勿用於本研究室，以免產生額外費用。

如何開始實驗室及登入 Google Cloud 控制台

  1. 按一下「Start Lab」按鈕。如果實驗室會產生費用，畫面中會出現選擇付款方式的彈出式視窗。左側的「Lab Details」窗格會顯示下列項目：

    • 「Open Google Cloud console」按鈕
    • 剩餘時間
    • 必須在這個實驗室使用的臨時憑證
    • 完成這個實驗室所需的其他資訊 (如有)

  2. 點選「Open Google Cloud console」；如果使用 Chrome 瀏覽器，也可以按一下滑鼠右鍵，選取「在無痕視窗中開啟連結」。

    接著，實驗室會啟動相關資源並開啟另一個分頁，當中顯示「登入」頁面。

    提示：您可以在不同的視窗中並排開啟分頁。

    注意：頁面中顯示「選擇帳戶」對話方塊時，請點選「使用其他帳戶」。

  3. 如有必要，請將下方的 Username 貼到「登入」對話方塊。

    {{{user_0.username | "Username"}}}

    您也可以在「Lab Details」窗格找到 Username。

  4. 點按「Next」。

  5. 複製下方的 Password，並貼到「歡迎使用」對話方塊。

    {{{user_0.password | "Password"}}}

    您也可以在「Lab Details」窗格找到 Password。

  6. 點選「下一步」。

    重要事項：請務必使用實驗室提供的憑證，而非自己的 Google Cloud 帳戶憑證。 注意：如果使用自己的 Google Cloud 帳戶來進行這個實驗室，可能會產生額外費用。

  7. 按過後續的所有頁面：

    • 接受條款及細則。
    • 由於這是臨時帳戶，請勿新增救援選項或雙重驗證機制。
    • 請勿申請免費試用。

Google Cloud 控制台稍後會在這個分頁開啟。

注意：如要查看列出 Google Cloud 產品和服務的選單，請點選左上角的「導覽選單」。「導覽選單」圖示

啟動 Cloud Shell

Cloud Shell 是搭載多項開發工具的虛擬機器，提供永久的 5 GB 主目錄，而且在 Google Cloud 中運作。Cloud Shell 提供指令列存取權，方便您使用 Google Cloud 資源。

  1. 點按 Google Cloud 控制台頂端的「啟用 Cloud Shell」圖示 「啟動 Cloud Shell」圖示。

連線建立完成即代表通過驗證，而且專案已設為您的 Project_ID：。輸出內容中有一行文字，宣告本工作階段的 Project_ID：

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud 是 Google Cloud 的指令列工具，已預先安裝於 Cloud Shell，並支援 Tab 鍵自動完成功能。

  1. (選用) 您可以執行下列指令來列出使用中的帳戶：
gcloud auth list
  1. 點按「授權」。

輸出內容：

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (選用) 您可以使用下列指令來列出專案 ID：
gcloud config list project

輸出內容：

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注意：如需 gcloud 的完整說明，請前往 Google Cloud 參閱 gcloud CLI 總覽指南。

環境設定

在 Cloud Shell 設定專案的專案 ID 和專案編號，分別儲存為 PROJECT_ID 和 PROJECT_NUMBER 變數。

export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \ --format='value(projectNumber)')

啟用服務

啟用所有必要服務：

gcloud services enable \ cloudkms.googleapis.com \ cloudbuild.googleapis.com \ container.googleapis.com \ containerregistry.googleapis.com \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ ondemandscanning.googleapis.com \ binaryauthorization.googleapis.com

工作 1：建立 Artifact Registry 存放區

在本實驗室中，您將使用 Artifact Registry 儲存及掃描映像檔。

  1. 使用下列指令建立存放區：
gcloud artifacts repositories create artifact-scanning-repo \ --repository-format=docker \ --location={{{ project_0.default_region | "REGION" }}} \ --description="Docker repository"
  1. 設定 Docker，在存取 Artifact Registry 時使用 gcloud 憑證：
gcloud auth configure-docker {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev
  1. 建立並變更為工作目錄：
mkdir vuln-scan && cd vuln-scan
  1. 接下來，定義範例映像檔。建立名為 Dockerfile 的檔案，包含下列內容：
cat > ./Dockerfile << EOF FROM python:3.8-alpine # App WORKDIR /app COPY . ./ RUN pip3 install Flask==2.1.0 RUN pip3 install gunicorn==20.1.0 RUN pip3 install Werkzeug==2.2.2 CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app EOF
  1. 建立名為 main.py 的檔案，加入下列內容：
cat > ./main.py << EOF import os from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): name = os.environ.get("NAME", "Worlds") return "Hello {}!".format(name) if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080))) EOF
  1. 使用 Cloud Build 建構容器，並自動推送至 Artifact Registry。
gcloud builds submit . -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

點選「Check my progress」，確認目標已達成。 建立 Artifact Registry 存放區。

工作 2：映像檔簽署

什麼是驗證者

  • 這個人員/程序是系統信任鏈的一個環節。
  • 驗證者持有加密編譯金鑰，在映像檔通過核准程序後加以簽署。
  • 政策建立者會決定政策概念框架，驗證者則負責具體執行政策的某些層面。
  • 驗證者可以是真人 (例如 QA 測試人員或管理員)，也可以是 CI 系統中的機器人。
  • 維持驗證者的私密金鑰安全相當重要，因為這攸關驗證的可信任度，進而影響系統的安全性。

這些角色可代表貴機構中的個人或團隊，在正式環境中可能分由不同的 Google Cloud Platform 專案管理，而各角色會透過 Cloud IAM 有限度共用專案間的資源存取權。

驗證者階層的運作方式

二進位授權中的驗證者是根據 Cloud Container Analysis API 實作，因此請務必先瞭解該 API 的運作方式，再繼續下一步。Container Analysis API 的設計宗旨，是讓使用者將中繼資料與特定容器映像檔建立關聯。

舉例來說，您可以建立附註來追蹤 Heartbleed 安全漏洞。安全廠商接著會建立掃描器，測試容器映像檔是否有安全漏洞，並為每個遭入侵容器建立關聯例項。

208aa5ebc53ff2b3.png

除了追蹤安全漏洞，容器分析也可做為一般中繼資料 API。二進位授權會使用容器分析功能，將簽章與要驗證的容器映像檔建立關聯。容器分析附註代表單一驗證者，且系統會針對驗證者核准的每個容器建立例項並進行關聯。

Binary Authorization API 使用「驗證者」與「驗證」的概念，但這些概念是透過 Container Analysis API 中的對應附註和例項實作。

容器分析流程圖

建立驗證者附註

驗證者附註只是一小份資料，可做為所套用簽章類型的標籤。舉例來說，某則附註可能指示安全漏洞掃描，另一則可能會用於 QA 簽核。執行簽署流程時會參考附註。

Container Analysis API 和二進位授權關係流程圖
  1. 建立附註：
cat > ./vulnz_note.json << EOM { "attestation": { "hint": { "human_readable_name": "Container Vulnerabilities attestation authority" } } } EOM
  1. 儲存附註
NOTE_ID=vulnz_note curl -vvv -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./vulnz_note.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"
  1. 驗證附註
curl -vvv \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

您的附註現已儲存在 Container Analysis API。

  1. 建立驗證者

驗證者會執行實際的映像檔簽署程序，並將附註的例項附加至映像檔，以供日後驗證。如要使用驗證者，您也必須向二進位授權註冊附註：

驗證者與附註的例項建立關聯
  1. 建立驗證者
ATTESTOR_ID=vulnz-attestor gcloud container binauthz attestors create $ATTESTOR_ID \ --attestation-authority-note=$NOTE_ID \ --attestation-authority-note-project=${PROJECT_ID}
  1. 檢查驗證者
gcloud container binauthz attestors list

最後一行會顯示 NUM_PUBLIC_KEYS: 0，您將在後續步驟中提供金鑰。

執行會產生映像檔的建構作業時，Cloud Build 會在專案中自動建立 built-by-cloud-build 驗證者。因此上述指令會傳回兩個驗證者：vulnz-attestor 和 built-by-cloud-build。映像檔建構完成後，Cloud Build 會自動簽署映像檔並建立驗證。

  1. 二進位授權服務帳戶需要查看驗證附註的權限。透過下列 API 呼叫，提供 IAM 角色的存取權：
PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)") BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com" cat > ./iam_request.json << EOM { 'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}', 'policy': { 'bindings': [ { 'role': 'roles/containeranalysis.notes.occurrences.viewer', 'members': [ 'serviceAccount:${BINAUTHZ_SA_EMAIL}' ] } ] } } EOM
  1. 使用檔案建立 IAM 政策：
curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./iam_request.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

點選「Check my progress」，確認目標已達成。 建立驗證者。

工作 3：新增 KMS 金鑰

您必須先讓授權單位建立可用於簽署容器映像檔的加密編譯金鑰組，才能使用這個驗證者。這項作業可透過 Google Cloud Key Management Service (KMS) 完成。

Google Cloud Key Management Service (KMS) 的圖表
  1. 首先，新增一些環境變數來描述新金鑰：
KEY_LOCATION=global KEYRING=binauthz-keys KEY_NAME=codelab-key KEY_VERSION=1
  1. 建立金鑰環來保存一組金鑰：
gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"
  1. 為驗證者建立新的非對稱簽署金鑰組
gcloud kms keys create "${KEY_NAME}" \ --keyring="${KEYRING}" --location="${KEY_LOCATION}" \ --purpose asymmetric-signing \ --default-algorithm="ec-sign-p256-sha256"

Cloud 控制台的 KMS 頁面應會顯示您的金鑰。

  1. 現在，透過 gcloud binauthz 指令將金鑰與驗證者建立關聯：
gcloud beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"
  1. 如果您再次列印授權單位清單，現在應該會看到已註冊的金鑰：
gcloud container binauthz attestors list

點選「Check my progress」，確認目標已達成。 新增 KMS 金鑰。

工作 4：建立已簽署的驗證

到了這個階段，您已經設定了簽署映像檔的功能。使用先前建立的驗證者簽署您使用的容器映像檔。

KMS 圖表，顯示驗證和事件連線

驗證必須包含密碼編譯簽章，說明驗證者已檢查特定容器映像檔，可在叢集上安全執行該映像檔。

  1. 如要指定要驗證的容器映像檔，請執行下列指令來判斷摘要：
CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \ --format='get(image_summary.digest)')
  1. 現在，您可以使用 gcloud 建立驗證。這項指令會輸入您要用於簽署的金鑰詳細資料，以及要核准的特定容器映像檔：
gcloud beta container binauthz attestations sign-and-create \ --artifact-url="${CONTAINER_PATH}@${DIGEST}" \ --attestor="${ATTESTOR_ID}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

以容器分析的用語來說，這會建立新例項，並附加至驗證者的附註。

  1. 為確保一切運作正常，請執行下列指令來列出驗證：
gcloud container binauthz attestations list \ --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

工作 5：許可控制政策

二進位授權是 GKE 和 Cloud Run 的一項功能，可在允許執行容器映像檔前驗證規則。無論是來自可信任的 CI/CD 管道，還是使用者手動嘗試部署映像檔，只要有執行映像檔的要求，系統就會執行驗證。與單獨檢查 CI/CD 管道相比，這項功能保護執行階段環境的效果更好。

如要瞭解這項功能，需修改預設 GKE 政策，強制執行嚴格的授權規則。

  1. 建立啟用二進位授權的 GKE 叢集：
gcloud beta container clusters create binauthz \ --zone {{{ project_0.default_zone | "ZONE" }}} \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
  1. 允許 Cloud Build 部署至這個叢集：
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/container.developer"

允許所有政策

請先驗證預設政策狀態，以及您部署任何映像檔的能力

  1. 查看現有政策：
gcloud container binauthz policy export
  1. 請注意，強制執行政策已設為 ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

  1. 部署範例，確認您可以部署任何內容：
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
  1. 確認部署作業是否正常運作：
kubectl get pods

您會看到下列輸出內容：

hello-server 的狀態為「運作中」
  1. 刪除部署作業：
kubectl delete pod hello-server

拒絕所有政策

現在更新政策，禁止顯示所有映像檔。

  1. 將現行政策匯出為可編輯的檔案：
gcloud container binauthz policy export > policy.yaml
  1. 在文字編輯器中開啟 policy.yaml' 檔案，並將 evaluationMode 從 `ALWAYS_ALLOW 變更為 ALWAYS_DENY：
edit policy.yaml

確認編輯後的政策 YAML 檔案如下所示：

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_DENY enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

這項政策相對簡單，globalPolicyEvaluationMode 行會宣告這項政策會擴充 Google 定義的全域政策。這樣一來，所有官方 GKE 容器預設都能執行。此外，這項政策會宣告 defaultAdmissionRule，指出所有其他 Pod 都會遭到拒絕。許可規則包含 enforcementMode 行，指出應禁止不符合這項規則的所有 Pod 在叢集上執行。

如需建構更複雜政策的操作說明，請參閱 二進位授權說明文件。

二進位授權政策流程圖，僅允許指定容器
  1. 在 Cloud Shell 中執行下列指令，套用新政策：
gcloud container binauthz policy import policy.yaml

請稍候片刻，等待變更生效。

  1. 嘗試部署範例工作負載：
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
  1. 部署作業失敗，並顯示下列訊息：
Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

將政策還原為允許所有項目

繼續進行下一節的操作之前，請還原政策變更。

  1. 在文字編輯器中，將 evaluationMode 從 ALWAYS_DENY 變更為 ALWAYS_ALLOW。
edit policy.yaml

編輯後的政策 YAML 檔案應如下所示：

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_ALLOW enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy
  1. 套用還原的政策：
gcloud container binauthz policy import policy.yaml

點選「Check my progress」，確認目標已達成。 建立 GKE 叢集並更新政策。

工作 6：自動簽署映像檔

您已啟用映像檔簽署功能，並手動使用驗證者簽署範例映像檔。在實務中，您會在自動化程序 (例如 CI/CD 管道) 中套用驗證。

在本節中，您將設定 Cloud Build 自動驗證映像檔。

所需角色

  1. 將二進位授權驗證者檢視者角色新增至 Cloud Build 服務帳戶：
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/binaryauthorization.attestorsViewer
  1. 將 Cloud KMS CryptoKey Signer/Verifier 角色新增至 Cloud Build 服務帳戶 (KMS 型簽署)：
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/cloudkms.signerVerifier gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ --role roles/cloudkms.signerVerifier
  1. 將容器分析註記連結者角色新增至 Cloud Build 服務帳戶：
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/containeranalysis.notes.attacher

提供 Cloud Build 服務帳戶的存取權

Cloud Build 必須具備 On-Demand Scanning API 的存取權。

  • 使用下列指令提供存取權：
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/iam.serviceAccountUser" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/ondemandscanning.admin"

準備自訂建構 Cloud Build 步驟

您將在 Cloud Build 中使用自訂建構步驟，簡化驗證程序。Google 提供的這個自訂建構步驟包含輔助函式，可簡化程序。在使用前，必須先將自訂建構步驟的程式碼建構成容器，並推送至 Cloud Build。

  • 請執行下列指令來進行這項操作：
git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git cd cloud-builders-community/binauthz-attestation gcloud builds submit . --config cloudbuild.yaml cd ../.. rm -rf cloud-builders-community

在 cloudbuild.yaml 中新增簽署步驟

在 Cloud Build 管道中新增驗證步驟。

  1. 請參閱下方的簽署步驟。

僅供檢閱，請勿複製

#Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'
  1. 編寫 cloudbuild.yaml 檔案，其中包含下列完整管道：
cat > ./cloudbuild.yaml << EOF steps: # build - id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.'] waitFor: ['-'] # additional CICD checks (not shown) #Retag - id: "retag" name: 'gcr.io/cloud-builders/docker' args: ['tag', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #pushing to artifact registry - id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION' images: - {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good EOF
  1. 執行版本：
gcloud builds submit

在 Cloud Build 記錄中查看建構作業

在 Cloud 控制台中，前往「Cloud Build」>「建構作業記錄」頁面，查看最新建構作業和建構步驟是否成功執行。

點選「Check my progress」，確認目標已達成。 新增簽署步驟。

工作 7：授權已簽署的映像檔

現在您將更新 GKE，使用二進位授權驗證映像檔是否具有安全漏洞掃描的簽章，再允許映像檔執行。

二進位授權會驗證受信任和不受信任的映像檔

更新 GKE 政策以要求驗證

在 GKE BinAuth 政策中新增 clusterAdmissionRules，要求映像檔必須由驗證者簽署

目前叢集執行的政策只有一項規則：允許來自官方存放區的容器，拒絕所有其他容器。

  1. 使用下列指令，以更新版設定覆寫政策：
COMPUTE_ZONE={{{ project_0.default_region | "REGION" }}} cat > binauth_policy.yaml << EOM defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: REQUIRE_ATTESTATION requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: ${COMPUTE_ZONE}.binauthz: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor EOM
  1. 現在磁碟上應該會有一個名為 updated_policy.yaml 的新檔案。現在，系統會先檢查驗證者是否通過驗證，而不是按預設規則直接拒絕所有映像檔。
允許的容器，以及由驗證者簽署的容器
  1. 將新政策上傳至二進位授權：
gcloud beta container binauthz policy import binauth_policy.yaml

部署已簽署的映像檔

  1. 取得良好映像檔的摘要：
CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \ --format='get(image_summary.digest)')
  1. 在 Kubernetes 設定中使用摘要：
cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM
  1. 將應用程式部署至 GKE
kubectl apply -f deploy.yaml

前往 Cloud 控制台，依序點選「Kubernetes Engine」>「工作負載」，確認映像檔已成功部署。

點選「Check my progress」，確認目標已達成。 部署已簽署的映像檔。

工作 8：封鎖未簽署的映像檔

建構映像檔

  1. 使用本機 Docker 將映像檔建構至本機快取：
docker build -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .
  1. 將未簽署的映像檔推送至存放區：
docker push {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad
  1. 取得不良映像檔的摘要：
CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \ --format='get(image_summary.digest)')
  1. 在 Kubernetes 設定中使用摘要：
cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM
  1. 嘗試將應用程式部署至 GKE
kubectl apply -f deploy.yaml

檢視控制台中的工作負載，並記下指出部署作業遭拒絕的錯誤：

找不到有效且由驗證者信任的金鑰簽署驗證

點選「Check my progress」，確認目標已達成。 部署未簽署的映像檔。

恭喜！

您已瞭解如何建立驗證者簽署映像檔以驗證規則，然後才能執行容器映像檔。您已學會如何編寫政策，讓 Cloud Build 允許或拒絕存取 GKE 叢集，並搭配使用二進位授權和 Google Cloud KMS 驗證映像檔簽章，防止未簽署的映像檔存取 Kubernetes 叢集。

後續步驟/瞭解詳情

Google Cloud 教育訓練與認證

協助您瞭解如何充分運用 Google Cloud 的技術。我們的課程會介紹專業技能和最佳做法，讓您快速掌握要領並持續進修。訓練課程涵蓋基本到進階等級，您可自行安排時間，選擇以隨選、線上或虛擬方式參加。認證可協助您驗證及證明自己在 Google Cloud 技術方面的技能和專業知識。

使用手冊上次更新日期：2024 年 9 月 10 日

實驗室上次測試日期：2024 年 7 月 11 日

Copyright 2024 Google LLC 保留所有權利。Google 和 Google 標誌是 Google LLC 的商標，所有其他公司和產品名稱可能是其關聯公司的商標。

准备工作

  1. 实验会创建一个 Google Cloud 项目和一些资源，供您使用限定的一段时间
  2. 实验有时间限制，并且没有暂停功能。如果您中途结束实验，则必须重新开始。
  3. 在屏幕左上角，点击开始实验即可开始

使用无痕浏览模式

  1. 复制系统为实验提供的用户名和密码
  2. 在无痕浏览模式下，点击打开控制台

登录控制台

  1. 使用您的实验凭证登录。使用其他凭证可能会导致错误或产生费用。
  2. 接受条款，并跳过恢复资源页面
  3. 除非您已完成此实验或想要重新开始，否则请勿点击结束实验，因为点击后系统会清除您的工作并移除该项目

此内容目前不可用

一旦可用，我们会通过电子邮件告知您

太好了！

一旦可用，我们会通过电子邮件告知您

一次一个实验

确认结束所有现有实验并开始此实验

使用无痕浏览模式运行实验

Using an Incognito or private browser window is the best way to run this lab. This prevents any conflicts between your personal account and the Student account, which may cause extra charges incurred to your personal account.