本頁面由 Cloud Translation API 翻譯而成。

使用二進位檔驗證控管部署作業

1. 簡介

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

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

Cloud Build 二進位授權認證管道。 **圖 1.**建立二進位授權認證的 Cloud Build 管道。

在這個管道中：

用於建構容器映像檔的程式碼會推送至原始碼存放區，例如 Cloud Source Repositories。
Cloud Build 是一項持續整合 (CI) 工具，可用來建構及測試容器。
建構作業會將容器映像檔推送至 Container Registry，或其他儲存您建構映像檔的註冊資料庫。
Cloud Key Management Service 為加密編譯金鑰金鑰組提供金鑰管理服務，負責簽署容器映像檔。產生的簽章會儲存於新建立的認證中。
在部署期間，驗證者會使用金鑰組的公開金鑰驗證認證。二進位授權會要求簽署認證才能部署容器映像檔，藉此強制執行政策。

在本研究室中，您將著重介紹保護部署構件的工具和技術。本研究室聚焦在建立完成但尚未部署至任何特定環境的構件 (容器) 之後，

課程內容

映像檔簽署
許可控管政策
簽署掃描的圖片
授權已簽署的圖片
已封鎖未簽署的映像檔

2. 設定和需求

自修環境設定

登入 Google Cloud 控制台，建立新專案或重複使用現有專案。如果您還沒有 Gmail 或 Google Workspace 帳戶，請先建立帳戶。

「專案名稱」是這項專案參與者的顯示名稱。這是 Google API 未使用的字元字串。您可以隨時更新。
所有 Google Cloud 專案的專案 ID 均不得重複，而且設定後即無法變更。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. 映像檔簽署

什麼是驗證者

驗證者

此人員/程序負責系統信任鏈結中的一個連結。
使用者持有加密編譯金鑰，並在圖片通過核准程序後簽署圖片。
政策建立者會以概略、抽象的方式判定政策，但驗證者須負責具體執行政策的某些部分。
可以是真人 (例如品質確保測試人員或主管)，也可以是 CI 系統中的機器人。
系統的安全性取決於其可信度，因此請務必保護他們的私密金鑰。

每種角色都可以代表個人或機構成員團隊。在實際工作環境中，這些角色可能會由不同的 Google Cloud Platform (GCP) 專案管理，資源存取權也會以有限的方式，使用 Cloud IAM。

二進位授權中的驗證者是以 Cloud Container Analysis API 為基礎進行實作，因此請務必先說明這項作業的運作方式。Container Analysis API 旨在讓您將中繼資料與特定容器映像檔建立關聯。

舉例來說，系統可能會建立記事來追蹤 Heartbleed 安全漏洞。安全廠商接著可以建立掃描器來測試容器映像檔是否有安全漏洞，並建立與每個遭入侵容器相關聯的發生情況。

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

Binary Authorization API 採用「驗證者」的概念和「認證」，不過是使用 Container Analysis API 中對應的附註和例項進行導入。

建立驗證者附註

「驗證者附註」僅是一小段資料，可做為套用簽名類型的標籤。舉例來說，某個附註可能表示安全漏洞掃描，另一個則用於品質確保簽署程序。我們會在簽署過程中提供附註說明。

建立記事

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，指出其他廣告連播都會遭到拒絕。許可規則包含 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 簽署者/驗證者角色新增至 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 必須取得權限，才能存取隨選掃描 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 政策以要求認證

將 clusterAdmissionRules 新增至 GKE BinAuth 政策，要求驗證者簽署映像檔

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

使用下列指令，以更新的設定覆寫政策。

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. 恭喜！

恭喜，您已完成程式碼研究室！

本文涵蓋的內容：

映像檔簽署
許可控管政策
簽署掃描的圖片
授權已簽署的圖片
已封鎖未簽署的映像檔

下一步：

清除所用資源

如要避免系統向您的 Google Cloud 帳戶收取本教學課程所用資源的費用，請刪除含有相關資源的專案，或者保留專案但刪除個別資源。

刪除專案

如要避免付費，最簡單的方法就是刪除您針對教學課程建立的專案。

—

上次更新時間：2023 年 3 月 21 日

使用二進位檔驗證控管部署作業

1. 簡介

課程內容

2. 設定和需求

自修環境設定

環境設定

啟用服務

建立 Artifact Registry 存放區

建立工作目錄並變更為工作目錄

定義範例圖片

建構映像檔並推送至 AR

3. 映像檔簽署

什麼是驗證者

建立驗證者附註

建立記事

儲存記事

驗證附註

建立驗證者

建立驗證者

驗證驗證者

新增 IAM 角色

新增 KMS 金鑰

建立已簽署的認證

4. 許可控管政策

建立 GKE 叢集

允許所有政策

拒絕所有政策

還原政策以允許所有流量

5. 簽署掃描的圖片

角色

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

準備自訂建構 Cloud Build 步驟

新增簽署步驟至 cloudbuild.yaml

執行版本

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

6. 授權已簽署的圖片

更新 GKE 政策以要求認證

部署已簽署的映像檔

7. 已封鎖未簽署的映像檔

建構映像檔

8. 恭喜！

本文涵蓋的內容：

下一步：

清除所用資源

刪除專案