1. 簡介
二進位授權是部署作業期間的安全性控管機制，可確保只有受信任的容器映像檔能部署至 Google Kubernetes Engine (GKE) 或 Cloud Run。使用二進位授權後，您就能要求受信任的單位在開發過程中簽署映像檔，然後在部署時強制執行簽章驗證程序。透過強制執行驗證程序，您可以確保僅將已通過驗證的映像檔整合至建構與發布的流程，更嚴謹控管容器環境。
下圖顯示二進位授權/Cloud Build 設定中的元件：
**圖 1。**建立二進位授權驗證的 Cloud Build 管道。
在這個管道中：
- 建構容器映像檔的程式碼會推送至來源存放區，例如 Cloud Source Repositories。
- 持續整合 (CI) 工具 Cloud Build 會建構及測試容器。
- 建構作業會將容器映像檔推送至 Container Registry 或其他儲存建構映像檔的登錄檔。
- Cloud Key Management Service 會為加密編譯金鑰組提供金鑰管理服務，並簽署容器映像檔。產生的簽章會儲存在新建立的驗證中。
- 部署時，驗證者會使用金鑰組的公開金鑰確認驗證。二進位授權會強制執行政策，要求提供已簽署的驗證，才能部署容器映像檔。
在本實驗室中，您將著重於運用工具和技術，確保部署的構件安全無虞。本實驗室將著重在建立好但尚未部署至任何特定環境的構件 (容器)。
課程內容
- 映像檔簽署
- 許可控制政策
- 簽署掃描的映像檔
- 授權已簽署的映像檔
- 封鎖未簽署的映像檔
2. 設定和需求
自修實驗室環境設定
- 登入 Google Cloud 控制台，然後建立新專案或重複使用現有專案。如果沒有 Gmail 或 Google Workspace 帳戶，請先建立帳戶。
- 專案名稱是這個專案參與者的顯示名稱。這是 Google API 未使用的字元字串。你隨時可以更新該位置資訊。
- 專案 ID 在所有 Google Cloud 專案中都是不重複的，而且設定後即無法變更。Cloud 控制台會自動產生不重複的字串，通常您不需要在意這個字串。在大多數程式碼研究室中，您需要參照專案 ID (通常會標示為
PROJECT_ID)。如果您不喜歡產生的 ID，可以產生另一個隨機 ID。你也可以嘗試使用自己的名稱，看看是否可用。完成這個步驟後就無法變更，且專案期間都會維持這個設定。 - 請注意，部分 API 會使用第三個值，也就是「專案編號」。如要進一步瞭解這三種值，請參閱說明文件。
- 接著，您需要在 Cloud 控制台中啟用帳單，才能使用 Cloud 資源/API。完成本程式碼研究室的費用應該不高，甚至完全免費。如要關閉資源，避免產生本教學課程以外的費用，您可以刪除自己建立的資源，或刪除整個專案。Google Cloud 新使用者可參加價值$300 美元的免費試用計畫。
環境設定
在 Cloud Shell 設定專案的專案 ID 和專案編號，分別儲存為 PROJECT_ID 和 PROJECT_ID 變數。
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
建立 Artifact Registry 存放區
在本實驗室中，您將使用 Artifact Registry 儲存及掃描映像檔。使用下列指令建立存放區。
gcloud artifacts repositories create artifact-scanning-repo \
--repository-format=docker \
--location=us-central1 \
--description="Docker repository"
設定 Docker，在存取 Artifact Registry 時使用 gcloud 憑證。
gcloud auth configure-docker us-central1-docker.pkg.dev
建立並變更為工作目錄
mkdir vuln-scan && cd vuln-scan
定義範例圖片
建立名為 Dockerfile 的檔案，其中含有下列內容。
cat > ./Dockerfile << EOF
from python:3.8-slim
# App
WORKDIR /app
COPY . ./
RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0
CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app
EOF
建立名為 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
建構映像檔並推送至 AR
使用 Cloud Build 建構容器，並自動推送至 Artifact Registry。
gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
3. 映像檔簽署
什麼是驗證者
驗證者
- 這個人員/程序是系統信任鏈的一個環節。
- 驗證者持有加密編譯金鑰，在映像檔通過核准程序後加以簽署。
- 政策建立者會決定政策概念框架，驗證者則負責具體執行政策的某些層面。
- 驗證者可以是真人 (例如 QA 測試人員或管理員)，也可以是 CI 系統中的機器人。
- 維持驗證者的私密金鑰安全相當重要，因為這攸關驗證的可信任度，進而影響系統的安全性。
這些角色可代表貴機構中的個人或團隊，在正式環境中，這些角色可能分由不同的 Google Cloud Platform (GCP) 專案管理，而各角色會透過 Cloud IAM 有限度共用專案間的資源存取權。
二進位授權中的驗證者是根據 Cloud Container Analysis API 實作，因此請務必先瞭解該 API 的運作方式，再繼續下一步。Container Analysis API 的設計宗旨，是讓使用者將中繼資料與特定容器映像檔建立關聯。
舉例來說，您可以建立附註來追蹤 Heartbleed 安全漏洞。安全廠商接著會建立掃描器，測試容器映像檔是否有安全漏洞，並為每個遭入侵容器建立關聯例項。
除了追蹤安全漏洞，容器分析也可做為一般中繼資料 API。二進位授權會使用容器分析功能，將簽章與要驗證的容器映像檔建立關聯。容器分析附註代表單一驗證者，且系統會針對驗證者核准的每個容器建立例項並進行關聯。
Binary Authorization API 使用「驗證者」與「驗證」的概念，但這些概念是透過 Container Analysis API 中的對應附註和例項實作。
建立驗證者附註
驗證者附註只是一小份資料，可做為所套用簽章類型的標籤。舉例來說，某則附註可能指示安全漏洞掃描，另一則可能會用於 QA 簽核。執行簽署流程時會參考附註。
建立記事
cat > ./vulnz_note.json << EOM
{
"attestation": {
"hint": {
"human_readable_name": "Container Vulnerabilities attestation authority"
}
}
}
EOM
儲存附註
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}"
驗證附註
curl -vvv \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"
您的附註現已儲存在 Container Analysis API。
建立驗證者
驗證者會執行實際的映像檔簽署程序，並將附註的例項附加至映像檔，以供日後驗證。如要使用驗證者，您也必須向二進位授權註冊附註：
建立驗證者
ATTESTOR_ID=vulnz-attestor
gcloud container binauthz attestors create $ATTESTOR_ID \
--attestation-authority-note=$NOTE_ID \
--attestation-authority-note-project=${PROJECT_ID}
檢查驗證者
gcloud container binauthz attestors list
請注意，最後一行會顯示 NUM_PUBLIC_KEYS: 0，您將在後續步驟中提供金鑰
此外，執行會產生映像檔的建構作業時，Cloud Build 會在專案中自動建立 built-by-cloud-build 驗證者。因此上述指令會傳回兩個驗證者：vulnz-attestor 和 built-by-cloud-build。映像檔建構完成後，Cloud Build 會自動簽署映像檔並建立驗證。
新增 IAM 角色
二進位授權服務帳戶需要查看驗證附註的權限。透過下列 API 呼叫提供存取權
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
使用檔案建立 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"
新增 KMS 金鑰
您必須先讓授權單位建立可用於簽署容器映像檔的加密編譯金鑰組，才能使用這個驗證者。這項作業可透過 Google Cloud Key Management Service (KMS) 完成。
首先，新增一些環境變數來描述新金鑰
KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1
建立金鑰環來保存一組金鑰
gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"
為驗證者建立新的非對稱簽署金鑰組
gcloud kms keys create "${KEY_NAME}" \
--keyring="${KEYRING}" --location="${KEY_LOCATION}" \
--purpose asymmetric-signing \
--default-algorithm="ec-sign-p256-sha256"
Google Cloud 控制台的 KMS 頁面應會顯示您的金鑰。
現在，透過 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}"
如果您再次列印授權單位清單，現在應該會看到已註冊的金鑰：
gcloud container binauthz attestors list
建立已簽署的驗證
到了這個階段，您已經設定了簽署映像檔的功能。使用先前建立的驗證者簽署您使用的容器映像檔。
驗證必須包含密碼編譯簽章，說明驗證者已檢查特定容器映像檔，可在叢集上安全執行該映像檔。如要指定要驗證的容器映像檔，您需要判斷其摘要。
CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
--format='get(image_summary.digest)')
現在，您可以使用 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}"
以容器分析的用語來說，這會建立新例項，並附加至驗證者的附註。為確保一切運作正常，您可以列出驗證
gcloud container binauthz attestations list \
--attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}
4. 許可控制政策
二進位授權是 GKE 和 Cloud Run 的一項功能，可在允許執行容器映像檔前驗證規則。無論是來自可信任的 CI/CD 管道，還是使用者手動嘗試部署映像檔，只要有執行映像檔的要求，系統就會執行驗證。與單獨檢查 CI/CD 管道相比，這項功能保護執行階段環境的效果更好。
如要瞭解這項功能，需修改預設 GKE 政策，強制執行嚴格的授權規則。
建立 GKE 叢集
建立啟用二進位授權的 GKE 叢集：
gcloud beta container clusters create binauthz \
--zone us-central1-a \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
允許 Cloud Build 部署至這個叢集：
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/container.developer"
允許所有政策
請先驗證預設政策狀態，以及您部署任何映像檔的能力
- 查看現有政策
gcloud container binauthz policy export
- 請注意，強制執行政策已設為
ALWAYS_ALLOW
evaluationMode: ALWAYS_ALLOW
- 部署範例，確認您可以部署任何內容
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
- 確認部署作業是否正常運作
kubectl get pods
您會看到下列輸出內容
- 刪除部署作業
kubectl delete pod hello-server
拒絕所有政策
現在更新政策，禁止顯示所有映像檔。
- 將現行政策匯出為可編輯的檔案
gcloud container binauthz policy export > 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 在叢集上執行。
如需建構更複雜政策的操作說明，請參閱 二進位授權說明文件。
- 開啟終端機並套用新政策，然後稍候片刻，等待變更生效
gcloud container binauthz policy import policy.yaml
- 嘗試部署範例工作負載
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
- 部署作業失敗，並顯示下列訊息
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
將政策還原為允許所有項目
繼續進行下一節的操作之前，請務必還原政策變更
- 變更政策
在文字編輯器中，將 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
- 套用還原的政策
gcloud container binauthz policy import policy.yaml
5. 簽署掃描的映像檔
您已啟用映像檔簽署功能，並手動使用驗證者簽署範例映像檔。在實務中，您會在自動化程序 (例如 CI/CD 管道) 中套用驗證。
在本節中，您將設定 Cloud Build 自動驗證映像檔。
角色
將二進位授權驗證者檢視者角色新增至 Cloud Build 服務帳戶：
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role roles/binaryauthorization.attestorsViewer
將 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
將容器分析註記連結者角色新增至 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 管道中新增驗證步驟。
- 請參閱下方的簽署步驟。
僅供檢閱，請勿複製
#Sign the image only if the previous severity check passes
- id: 'create-attestation'
name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
args:
- '--artifact-url'
- 'us-central1-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'
- 編寫 cloudbuild.yaml 檔案，其中包含下列完整管道。
cat > ./cloudbuild.yaml << EOF
steps:
# build
- id: "build"
name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
waitFor: ['-']
#Run a vulnerability scan at _SECURITY level
- id: scan
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
(gcloud artifacts docker images scan \
us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
--location us \
--format="value(response.scan)") > /workspace/scan_id.txt
#Analyze the result of the scan
- id: severity check
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
--format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi
#Retag
- id: "retag"
name: 'gcr.io/cloud-builders/docker'
args: ['tag', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-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', 'us-central1-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'
- 'us-central1-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:
- us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF
執行建構作業
gcloud builds submit
在 Cloud Build 記錄中查看建構作業
開啟 Cloud 控制台的 Cloud Build 記錄頁面，查看最新建構作業和建構步驟是否成功執行。
6. 授權已簽署的映像檔
在本節中，您將更新 GKE，使用二進位授權驗證映像檔是否具有安全漏洞掃描的簽章，再允許映像檔執行。
更新 GKE 政策以要求驗證
在 GKE BinAuth 政策中新增 clusterAdmissionRules，要求映像檔必須由驗證者簽署
目前叢集執行的政策只有一項規則：允許來自官方存放區的容器，拒絕所有其他容器。
使用下列指令，以更新版設定覆寫政策。
COMPUTE_ZONE=us-central1-a
cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
${COMPUTE_ZONE}.binauthz:
evaluationMode: REQUIRE_ATTESTATION
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
requireAttestationsBy:
- projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM
現在磁碟上應該會有一個名為 updated_policy.yaml 的新檔案。現在，系統會先檢查驗證者是否通過驗證，而不是按預設規則直接拒絕所有映像檔。
將新政策上傳至二進位授權：
gcloud beta container binauthz policy import binauth_policy.yaml
部署已簽署的映像檔
取得良好映像檔的摘要
CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
--format='get(image_summary.digest)')
在 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
將應用程式部署至 GKE
kubectl apply -f deploy.yaml
檢視控制台中的工作負載，並記下映像檔已成功部署。
7. 封鎖未簽署的映像檔
建構映像檔
在這個步驟中，您會使用本機 Docker 將映像檔建構至本機快取。
docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .
將未簽署的映像檔推送至存放區
docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad
取得不良映像檔的摘要
CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
--format='get(image_summary.digest)')
在 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
嘗試將應用程式部署至 GKE
kubectl apply -f deploy.yaml
檢視控制台中的工作負載，並記下指出部署作業遭拒絕的錯誤：
No attestations found that were valid and signed by a key trusted by the attestor
8. 恭喜！
恭喜，您已完成本程式碼研究室！
涵蓋內容：
- 映像檔簽署
- 許可控制政策
- 簽署掃描的映像檔
- 授權已簽署的映像檔
- 封鎖未簽署的映像檔
後續步驟：
- 保護部署至 Cloud Run 和 Google Kubernetes Engine 的映像檔 | Cloud Build 說明文件
- 快速入門導覽課程：為 GKE | Google Cloud 設定二進位授權政策
清除所用資源
如要避免系統向您的 Google Cloud 帳戶收取本教學課程所用資源的費用，請刪除含有相關資源的專案，或者保留專案但刪除個別資源。
刪除專案
如要避免付費，最簡單的方法就是刪除您為了本教學課程所建立的專案。
—
上次更新時間：2023 年 3 月 21 日