このページは Cloud Translation API によって翻訳されました。

安全なビルドとCloud Build、Artifact Registry、GKE を使用してデプロイする

1. はじめに

Container Analysis はコンテナ用の脆弱性スキャンとメタデータストレージを提供します。スキャンサービスは、Artifact Registry と Container Registry 内のイメージに対して脆弱性スキャンを実行してから生成されたメタデータを保存し、API を介して利用できるようにします。メタデータストレージには、脆弱性スキャン、Google Cloud サービス、サードパーティプロバイダなど、さまざまなソースからの情報を保存できます。

脆弱性スキャンは、自動またはオンデマンドで起動できます。

自動スキャンが有効になっている場合、スキャンは、Artifact Registry や Container Registry に新しいイメージが push されるたびに自動的にトリガーされます。脆弱性情報は、新しい脆弱性が発見されるたびに更新されます。
オンデマンドスキャンが有効になっている場合、ローカルイメージまたは Artifact Registry または Container Registry のイメージをスキャンするコマンドを実行する必要があります。オンデマンドスキャンでは、コンテナのスキャンをより柔軟に行うことができます。たとえば、ローカルにビルドされたイメージをスキャンし、脆弱性を修正してからレジストリに格納できます。スキャン結果はスキャンが完了してから最大 48 時間利用できます。スキャン後に脆弱性情報は更新されません。

Container Analysis を CI/CD パイプラインに統合すると、そのメタデータに基づいて意思決定を行うことができます。たとえば、Binary Authorization を使用して、信頼できるレジストリからの準拠イメージに対してのみデプロイを許可するデプロイポリシーを作成できます。

学習内容

自動スキャンを有効にする方法
オンデマンドスキャンを実行する方法
スキャンをビルドパイプラインに統合する方法
承認済みの画像に署名する方法
GKE アドミッションコントローラを使用してイメージをブロックする方法
署名付きの承認済みイメージのみを許可するように GKE を構成する方法

2. 設定と要件

セルフペース型の環境設定

Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。この場所はいつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。
なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。

次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクト全体を削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

Cloudshell エディタを起動する

このラボは、Google Cloud Shell エディタでの使用を想定して設計、テストされています。エディタにアクセスするには、次の操作を行います。

https://console.cloud.google.com で Google プロジェクトにアクセスします。
右上にある Cloud Shell エディタアイコンをクリックします。

ウィンドウの下部に新しいペインが開きます。

環境設定

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"

Artifact Registry にアクセスするときに gcloud 認証情報を使用するように Docker を構成します。

gcloud auth configure-docker us-central1-docker.pkg.dev

3. 自動スキャン

アーティファクトスキャンは、Artifact Registry または Container Registry に新しいイメージが push されるたびに自動的にトリガーされます。脆弱性情報は、新しい脆弱性が発見されるたびに更新されます。このセクションでは、Artifact Registry にイメージを push して結果を確認します。

作業ディレクトリを作成して変更する

mkdir vuln-scan && cd vuln-scan

サンプル画像を定義する

Dockerfile という名前のファイルを作成し、次の内容を追加します。

cat > ./Dockerfile << EOF
FROM gcr.io/google-appengine/debian9@sha256:ebffcf0df9aa33f342c4e1d4c8428b784fc571cdf6fbab0b31330347ca8af97a

# System
RUN apt update && apt install python3-pip -y

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==1.1.4
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 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 に push する

Cloud Build を使用してコンテナをビルドし、Artifact Registry に自動的に push します。画像のタグ bad をメモします。後で識別できるようにします。

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

画像の詳細を確認する

ビルドプロセスが完了したら、Artifact Registry ダッシュボードでイメージと脆弱性の結果を確認します。

Cloud コンソールで Artifact Registry を開きます。
artifact-scanning-repo をクリックして内容を表示します。
画像の詳細をクリックします。
画像の最新のダイジェストをクリックします。
スキャンが完了したら、イメージの [脆弱性] タブをクリックします。

[脆弱性] タブには、ビルドしたイメージの自動スキャンの結果が表示されます。

スキャンの自動化はデフォルトで有効になっています。Artifact Registry の設定で、自動スキャンをオフまたはオンにする方法を確認する。

4. オンデマンドスキャン

イメージをリポジトリに push する前にスキャンを実行する必要があるシナリオはさまざまです。たとえば、コンテナデベロッパーは、イメージをスキャンして問題を修正してから、コードをソース管理に push します。次の例では、結果に基づいてアクションを実行する前に、ローカルでイメージをビルドして分析します。

イメージをビルドする

この手順では、ローカル Docker を使用してローカルキャッシュにイメージをビルドします。

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image .

画像をスキャンする

イメージがビルドされたら、イメージのスキャンをリクエストします。スキャンの結果はメタデータサーバーに保存されます。ジョブが完了すると、メタデータサーバーの結果の場所が示されます。

gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --format="value(response.scan)" > scan_id.txt

出力ファイルを確認する

前のステップの出力（scan_id.txt ファイルに保存されている）を確認します。メタデータサーバー内のスキャン結果のレポートの場所を確認します。

cat scan_id.txt

スキャン結果の詳細を確認する

スキャンの実際の結果を表示するには、出力ファイルに記載されているレポートの場所に対して list-vulnerabilities コマンドを使用します。

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt)

出力には、イメージ内のすべての脆弱性に関する大量のデータが含まれます。

重大な問題を報告する

レポートに保存されているデータを直接使用することはほとんどありません。通常、結果は自動化されたプロセスで使用されます。次のコマンドを使用して、レポートの詳細を読み取り、重大な脆弱性が検出された場合はログに記録します。

export SEVERITY=CRITICAL

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq ${SEVERITY}; then echo "Failed vulnerability check for ${SEVERITY} level"; else echo "No ${SEVERITY} Vulnerabilities found"; fi

このコマンドの出力は次のようになります。

Failed vulnerability check for CRITICAL level

5. ビルドパイプラインのスキャン

このセクションでは、コンテナイメージをビルドしてスキャンし、結果を評価する自動ビルドパイプラインを作成します。重大な脆弱性が見つからない場合は、イメージがリポジトリに push されます。CRITICAL の脆弱性が見つかった場合、ビルドは失敗して終了します。

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 パイプラインを作成する

次のコマンドを実行すると、自動プロセスに使用される 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']

images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
EOF

CI パイプラインを実行する

ビルドを送信して処理し、重大度 CRITICAL の脆弱性が検出された場合にビルドが破棄されることを確認します。

gcloud builds submit

ビルドエラーを確認する

送信したビルドは、イメージに重大な脆弱性が含まれているため失敗します。

[Cloud Build 履歴] ページでビルドエラーを確認します。

脆弱性を修正する

CRITICAL の脆弱性が含まれていないベースイメージを使用するように Dockerfile を更新します。

次のコマンドを使用して、Debian 10 イメージを使用するように 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

正常な画像で CI プロセスを実行する

ビルドを送信して処理し、重大度 CRITICAL の脆弱性が見つからない場合にビルドが成功することを確認します。

gcloud builds submit

ビルドの成功を確認する

更新されたイメージに CRITICAL 脆弱性がないため、送信したビルドは成功します。

Cloud Build の履歴ページでビルドの成功を確認します。

スキャン結果を確認する

Artifact Registry で正常なイメージを確認する

Cloud コンソールで Artifact Registry を開きます。
artifact-scanning-repo をクリックして内容を表示します。
画像の詳細をクリックします。
画像の最新のダイジェストをクリックします。
イメージの [脆弱性] タブをクリックします。

6. イメージの署名

認証者メモを作成する

構成証明ノートとは、適用される署名の種類のラベルとして機能する少量のデータです。たとえば、1 つのメモは脆弱性スキャンを示し、別のメモは 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}"

認証者の作成

認証者は、実際のイメージ署名プロセスの実行に使用され、後で検証できるようにメモの発生をイメージに関連付けます。後で使用するために認証者を作成します。

認証者を作成

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 認証者が自動的に作成されます。上記のコマンドは、2 つの構成証明者（vulnz-attestor と built-by-cloud-build）を返します。イメージが正常にビルドされると、Cloud Build が自動的に証明書に署名して作成します。

IAM ロールの追加

Binary Authorization サービスアカウントには、構成証明メモを表示する権限が必要です。次の 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 鍵の追加

構成証明者は、メモを添付して検証可能な署名を提供するために、暗号鍵が必要です。この手順では、Cloud Build が後でアクセスできるように 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}"

Container Analysis では、新しいオカレンスが作成され、証明書発行者のメモに添付されます。すべてが想定どおりに動作していることを確認するには、構成証明を一覧表示します。

gcloud container binauthz attestations list \
   --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

7. Cloud Build による署名

イメージ署名を有効にして、認証者を手動で使用してサンプルイメージに署名しました。実際には、CI/CD パイプラインなどの自動化されたプロセス中に構成証明を適用する必要があります。

このセクションでは、イメージを自動的に構成するように Cloud Build を構成します。

ロール

Cloud Build サービスアカウントに Binary Authorization 認証者 / 閲覧者のロールを追加します。

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

Cloud KMS 暗号鍵の署名者 / 検証者ロールを Cloud Build サービスアカウントに追加します。（KMS ベースの署名）

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

Cloud Build サービスアカウントに Container Analysis メモ添付者のロールを追加します。

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

カスタムビルドの Cloud Build ステップを準備する

Cloud Build のカスタムビルドステップを使用して、構成証明プロセスを簡素化します。Google が提供するこのカスタムビルドステップには、プロセスを効率化するためのヘルパー関数が含まれています。使用する前に、カスタムビルドステップのコードをコンテナにビルドし、Cloud Build に push する必要があります。この操作を行うには、次のコマンドを実行します。

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 の履歴] ページで、最新のビルドとビルドステップの正常な実行を確認します。

8. アドミッションコントロールポリシー

Binary Authorization は、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

ターミナルを開いて新しいポリシーを適用し、変更が反映されるまで数秒待ちます。

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

9. GKE で脆弱性をブロックする

このセクションでは、これまで学習したことを組み合わせて、Cloud Build を使用して CI/CD パイプラインを実装します。このパイプラインは、イメージをスキャンし、脆弱性をチェックしてからイメージに署名してデプロイを試みます。GKE は、Binary Authorization を使用して、イメージの実行を許可する前に、イメージに脆弱性スキャンの署名があることを確認します。

構成証明を必須にするように 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

ポリシーを適用する

gcloud beta container binauthz policy import binauth_policy.yaml

未署名のイメージをデプロイする

次のコマンドを使用して、前にビルドしたアプリケーションのデプロイディスクリプタを作成します。ここで使用するイメージは、重大な脆弱性があり、署名付き構成証明が含まれていない、前述で作成したイメージです。

GKE アドミッションコントローラは、署名を一貫して検証するために、デプロイされる正確なイメージを把握する必要があります。そのためには、シンプルなタグではなく、イメージダイジェストを使用する必要があります。

不正な画像のイメージダイジェストを取得する

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

署名付きイメージをデプロイする

不正な画像のイメージダイジェストを取得する

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

コンソールでワークロードを確認し、イメージが正常にデプロイされたことを確認します。

10. 完了

お疲れさまでした。これでこの Codelab は終了です。

学習した内容

自動スキャンを有効にする方法
オンデマンドスキャンを実行する方法
スキャンをビルドパイプラインに統合する方法
承認済みの画像に署名する方法
GKE アドミッションコントローラを使用してイメージをブロックする方法
署名付きの承認済みイメージのみを許可するように GKE を構成する方法

次のステップ:

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

安全なビルドとCloud Build、Artifact Registry、GKE を使用してデプロイする

1. はじめに

学習内容

2. 設定と要件

セルフペース型の環境設定

Cloudshell エディタを起動する

環境設定

サービスを有効化する

Artifact Registry リポジトリを作成する

3. 自動スキャン

作業ディレクトリを作成して変更する

サンプル画像を定義する

イメージをビルドして AR に push する

画像の詳細を確認する

4. オンデマンド スキャン

イメージをビルドする

画像をスキャンする

出力ファイルを確認する

スキャン結果の詳細を確認する

重大な問題を報告する

5. ビルド パイプラインのスキャン

Cloud Build サービス アカウントにアクセス権を付与する

Cloud Build パイプラインを作成する

CI パイプラインを実行する

ビルドエラーを確認する

脆弱性を修正する

正常な画像で CI プロセスを実行する

ビルドの成功を確認する

スキャン結果を確認する

6. イメージの署名

認証者メモを作成する

メモを作成する

メモを保存する

メモを確認する

認証者の作成

認証者を作成

認証者の確認

IAM ロールの追加

KMS 鍵の追加

署名付き証明書を作成する

7. Cloud Build による署名

ロール

カスタムビルドの Cloud Build ステップを準備する

cloudbuild.yaml に署名ステップを追加する

ビルドを実行する

Cloud Build の履歴でビルドを確認する

8. アドミッション コントロール ポリシー

GKE クラスタを作成する

すべて許可ポリシー

すべて拒否ポリシー

ポリシーを元に戻してすべて許可する

9. GKE で脆弱性をブロックする

構成証明を必須にするように GKE ポリシーを更新

未署名のイメージをデプロイする

署名付きイメージをデプロイする

10. 完了

学習した内容

次のステップ:

クリーンアップ

プロジェクトの削除

4. オンデマンドスキャン

5. ビルドパイプラインのスキャン

Cloud Build サービスアカウントにアクセス権を付与する

8. アドミッションコントロールポリシー