GSP521

概要

チャレンジラボでは、シナリオと一連のタスクが提供されます。手順ガイドに沿って進める形式ではなく、コース内のラボで習得したスキルを駆使して、ご自身でタスクを完了していただきます。タスクが適切に完了したかどうかは、このページに表示される自動スコアリング システムで確認できます。

チャレンジラボは、Google Cloud の新しいコンセプトについて学習するためのものではありません。デフォルト値を変更する、エラー メッセージを読み調査を行ってミスを修正するなど、習得したスキルを応用する能力が求められます。

100% のスコアを達成するには、制限時間内に全タスクを完了する必要があります。

このラボは、「安全なソフトウェア デリバリー」コースに登録している受講者を対象としています。準備が整ったらチャレンジを開始しましょう。

チャレンジ シナリオ

Cymbal Bank のソフトウェア エンジニアとして、新しいウェブ アプリケーションをクラウドに安全にデプロイするタスクを任されているとします。このアプリケーションは機密性の高い顧客データを扱うため、セキュリティが最重要事項です。目標は、厳格なセキュリティ基準を遵守しながら、コンテナ化されたアプリケーションをビルド、スキャン、署名、デプロイする堅牢な自動化パイプラインを実装することです。このチャレンジでは、Artifact Registry、Binary Authorization、Cloud Build などの Google Cloud サービスを使用して、サンプル アプリケーションでこの目標を達成します。

テスト対象トピック

• Artifact Registry リポジトリの作成: スキャンと本番環境用の Docker イメージを保存する Artifact Registry リポジトリを設定します。
• Docker イメージの push: Cloud Build を介して Docker イメージをビルドし、脆弱性スキャンのために Artifact Registry に push します。
• Binary Authorization の設定: 認証者と鍵を使用して Binary Authorization を構成し、イメージ署名ポリシーを適用します。
• 脆弱性スキャンの結果の表示: Artifact Registry 内の脆弱性スキャンの結果を調べて、潜在的なセキュリティ リスクを特定して把握します。
• 安全な CI / CD パイプラインの作成: イメージのビルド、脆弱性スキャン、イメージ署名を自動化する Cloud Build パイプラインを構築します。
• レビューと修正: 重大な脆弱性によって失敗したビルドの原因を分析し、アプリケーション コードの問題を修正します。
• 再構築とデプロイ: 修正したコードで CI / CD パイプラインを再実行し、Cloud Run へのデプロイが成功するか確認します。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

タスク 1. API を有効にして環境をセットアップする

安全な CI / CD パイプラインの構築を開始する前に、必要な Google Cloud API を有効にして、開発環境を設定する必要があります。これにより、必要なすべてのサービスとツールにアクセスできるようになります。

1. このラボで必要な以下の API を有効にします。

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

2. Cloud Shell で次のコマンドを実行して、サンプルの Python、Docker、Cloud Build ファイルをダウンロードします。

mkdir sample-app && cd sample-app gcloud storage cp gs://spls/gsp521/* .

3. Artifact Registry リポジトリを 2 つ作成します（スキャン用と本番環境用）。リポジトリにそれぞれ artifact-scanning-repo と artifact-prod-repo という名前を付けます。

スキャン リポジトリは、脆弱性がスキャンされる前の Docker イメージを保存するために使用され、本番環境リポジトリは、署名されてデプロイの準備が整った後のイメージを保存するために使用されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

API を有効にして、Artifact Registry を設定します。

タスク 2. Cloud Build パイプラインを作成する

このタスクでは、Docker イメージをビルドして Artifact Registry に push するための基本的な Cloud Build 構成を作成し、CI / CD パイプラインの基盤を築きます。この最初のステップにより、ラボの後半でイメージの脆弱性をスキャンできるようになります。

1. まず、Cloud Build サービス アカウントに次のロールを追加します。

   • roles/iam.serviceAccountUser
   • roles/ondemandscanning.admin

2. Cloud Shell エディタで、sample-app/cloudbuild.yaml ファイルを開きます。

3. TODO を完了する: イメージ名のプレースホルダ（<image-name>）を入力します。これには、artifact-scanning-repo リポジトリを参照する必要があります。イメージ名は sample-image にする必要があります。必ずリージョンを使用してください。

4. ビルドを送信します。

5. artifact-scanning-repo リポジトリに push したイメージを確認し、スキャン結果に多数の重大な脆弱性が表示されていることを確認します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

Cloud Build パイプラインを作成します。

タスク 3. Binary Authorization を設定する

コンテナ デプロイに厳格なセキュリティ ポリシーを適用するために、Binary Authorization を活用します。このサービスでは、どのイメージを誰がどのような条件でデプロイできるかを定義できます。このタスクでは、認証者、ノート、KMS 鍵など、Binary Authorization の必須コンポーネントを作成して構成します。これにより、Binary Authorization を CI / CD パイプラインに統合する準備が整います。

認証者を作成する

1. Cloud Shell で、JSON ファイルを作成します。このファイルは、認証のヒントを含む認証者向けノートを定義します。認証ヒントの human_readable_name を「Container Vulnerabilities attestation authority」に設定します。

2. Container Analysis API を使用して、ID が vulnerability_note の新しいノートを作成します。ノートの詳細は、前のステップで作成したノートファイルで定義する必要があります。API リクエストに適切な認証を含め、適切な Content-Type ヘッダーを設定してください。

3. Container Analysis API を使用して、作成したばかりの認証者向けノートの詳細を取得します。API リクエストに適切な認証を含めるようにしてください。

4. gcloud コマンドライン ツールを使用して、新しい Binary Authorization 認証者を作成します。認証者 ID は vulnerability-attestor にし、先ほど作成した認証者向けノートに関連付ける必要があります。

5. gcloud コマンドライン ツールを使用して、既存のすべての Binary Authorization 認証者を一覧表示します。作成した認証者がリストに含まれていることを確認します。

6. 作成した認証者向けノートに対して、Binary Authorization サービス アカウントに roles/containeranalysis.notes.occurrences.viewer ロールを付与する IAM ポリシーを構築します。次に、Container Analysis API を使用して、この IAM ポリシーをノートに設定します。

KMS ペアを生成する

このセクションでは、証明書に署名するための KMS 鍵ペアを生成します。

1. 鍵管理を設定する:

   • 鍵を保存するために、global ロケーションに binauthz-keys という名前の KMS キーリングを作成します。
   • このキーリング内で、新しい非対称署名鍵ペアを生成します。この鍵に lab-key という名前を付け、バージョン 1 になっていることを確認します。

2. 鍵を認証者にリンクさせる:

   • gcloud コマンドライン ツールを使用して、lab-key（バージョン 1）を Binary Authorization の認証者に関連付けます。キーを参照するときは、必ず global ロケーションと binauthz-keys キーリングを指定してください。

Binary Authorization ポリシーを更新する

1. ポリシーの変更: デフォルト ルールで証明書を要求するように Binary Authorization ポリシーを調整します。

2. 認証者を組み込む: ポリシー構成の一部として、以前に作成した vulnerability-attestor を含めます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

認証者と KMS ペアを作成し、ポリシーを更新します。

タスク 4. 脆弱性スキャンを備えた Cloud Build CI / CD パイプラインを作成する

タスク 2 の基本的なパイプラインを基に、重要なセキュリティ機能を組み込んでパイプラインを強化します。これには、コンテナ イメージの潜在的な弱点を特定する脆弱性スキャンや、イメージの完全性を確保するイメージ署名が含まれます。このタスクでは、脆弱性スキャンとイメージ署名を CI / CD パイプラインに組み込み、パイプラインをより堅牢かつ安全にします。

必要なロールを Cloud Build サービス アカウントに追加する

1. プロジェクトで Cloud Build サービス アカウントに次の IAM ロールを付与します。

   • roles/binaryauthorization.attestorsViewer
   • roles/cloudkms.signerVerifier
   • roles/containeranalysis.notes.attacher
   • roles/iam.serviceAccountUser
   • roles/ondemandscanning.admin

2. さらに、Compute Engine のデフォルトのサービス アカウントに cloudkms.signerVerifier ロールがあることを確認します。

カスタム ビルドステップをインストールする

1. 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

Cloud Build パイプラインを更新する

このセクションでは、脆弱性スキャン、重大度チェック、イメージ署名、Cloud Run へのデプロイを含めて Cloud Build パイプラインを完成させます。以下のコードは、パイプラインの実装の一部です。このパイプラインを完成させるには、欠けている部分を埋める必要があります。

1. TODO を完了する: パイプラインの欠けている部分を埋めます。具体的な手順は次のとおりです。
   • 脆弱性スキャン用に Artifact Registry のイメージの場所を指定します。なお、スキャン対象は artifact-scanning-repo リポジトリ内のイメージにしてください。
   • 脆弱性チェックに適切な重大度レベルを設定します。CRITICAL な脆弱性が検出された場合は、パイプラインを失敗させる必要があります。
   • 正しい認証者と KMS 鍵の情報を使用して、イメージ署名ステップを構成します。認証者の名前は vulnerability-attestor、鍵のバージョンは lab-key バージョン 1 のフルパスです。
   • 本番環境用にイメージを再度タグ付けし、本番環境リポジトリに push します。そのためには、artifact-prod-repo リポジトリを使用する必要があります。
   • Cloud Run にイメージをデプロイします。このステップでは、artifact-prod-repo リポジトリの本番環境用イメージを使用します。

注: このラボの 2 つ目のタスクで、cloudbuild.yaml ファイルの最初のいくつかの TODO はすでに記入済みです。残りの TODO についても、残っているプレースホルダを正しい値に置き換えてください。

cloudbuild.yaml

ステップ: # TODO 1: ビルドステップ。<image-name> プレースホルダを正しい値に置き換えます。- id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '<image-name>', '.'] waitFor: ['-'] # TODO 2: Artifact Registry に push します。<image-name> プレースホルダを正しい値に置き換えます。- id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '<image-name>'] # TODO 3: 脆弱性スキャンを実行します。<image-name> プレースホルダを正しい値に置き換えます。- id: scan name: 'gcr.io/cloud-builders/gcloud' entrypoint: 'bash' args: - '-c' - | (gcloud artifacts docker images scan \ <image-name> \ --location us \ --format="value(response.scan)") > /workspace/scan_id.txt # TODO 4: スキャンの結果を分析します。CRITICAL な脆弱性が検出された場合は、ビルドを失敗させます。 # <correct vulnerability> プレースホルダを正しい値に置き換えます。大文字と小文字は区別されます。- 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 <correct vulnerability>; \ then echo "Failed vulnerability check for <correct vulnerability> level" && exit 1; else echo \ "No <correct vulnerability> vulnerability found, congrats !" && exit 0; fi # TODO 5: 前の重大度チェックに合格した場合のみ、イメージに署名します。 # プレースホルダを正しい値（<image-name>、<attestor-name>、<key-version>）に置き換えます。 # <key-version> は、鍵のバージョンの **フル** パスにする必要があります。- id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '<image-name>' - '--attestor' - '<attestor-name>' - '--keyversion' - '<key-version>' # TODO 6: 本番環境用にイメージに再度タグを付け、最新のタグを使用して本番環境リポジトリに push します。 # <image-name> と <production-image-name> のプレースホルダを正しい値に置き換えます。 - id: "push-to-prod" name: 'gcr.io/cloud-builders/docker' args: - 'tag' - '<image-name>' - '<production-image-name>' - id: "push-to-prod-final" name: 'gcr.io/cloud-builders/docker' args: ['push', '<production-image-name>'] # TODO 7: Cloud Run にデプロイします。<image-name> と <your-region> のプレースホルダを正しい値に置き換えます。- id: 'deploy-to-cloud-run' name: 'gcr.io/cloud-builders/gcloud' entrypoint: 'bash' args: - '-c' - | gcloud run deploy auth-service --image=<image-name> \ --binary-authorization=default --region=<your-region> --allow-unauthenticated # TODO 8: <image-name> プレースホルダをビルドステップの値に置き換えます。 images: - <image-name>

3. ビルドをトリガーする

   • 作成した Cloud Build 構成を送信して、ビルドプロセスを開始します。
   • ビルドを送信する際は、作業しているリージョンに注意してください。

4. ビルドの失敗を確認する:

   • Google Cloud コンソールで Cloud Build の [履歴] ページに移動します。
   • トリガーしたビルドを探して、そのステータスを確認します。
   • 重大度が CRITICAL の脆弱性が存在するため、ビルドが失敗することを確認します。

注: このビルドは、CRITICAL な脆弱性があるため失敗するはずです。この問題については次のタスクで対処します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

脆弱性スキャンを CI / CD パイプラインに組み込みます。

タスク 5. 脆弱性を修正し、CI / CD パイプラインを再デプロイする

実際のシナリオでは、脆弱性スキャンによって、対処が必要な問題が明らかになることがよくあります。このタスクはそのようなシナリオを再現しており、重大な脆弱性が原因でビルドが失敗します。このタスクでは、ビルドの失敗を分析し、脆弱性を特定して、アプリケーションの依存関係を更新することで脆弱性を修正します。次に、Cloud Build パイプラインを再トリガーして、重大な脆弱性がない状態でビルドが正常に完了することを確認します。

1. Dockerfile を更新する: python:3.8-alpine ベースイメージを使用するように Dockerfile を変更します。Flask、Gunicorn、Werkzeug の依存関係を次のバージョンに更新します。

   • Flask: 3.0.3
   • Gunicorn: 23.0.0
   • Werkzeug: 3.0.4

2. ビルドを再トリガーする: 更新した Cloud Build 構成を送信して、新しいビルドを開始します。

3. ビルドの成功を確認する: Cloud Build の [履歴] ページで、ビルドが CRITICAL な脆弱性の問題なく正常に完了したことを確認します。

4. テスト目的で次のコマンドを実行し、Cloud Run サービスへの未認証アクセスを許可し、デプロイを検証できるようにします。<your-region> は、サービスをデプロイしたリージョンに置き換えます。

gcloud beta run services add-iam-policy-binding --region=<your-region> --member=allUsers --role=roles/run.invoker auth-service 注: このコマンドはテスト目的でのみ使用し、本番環境では使用しないでください。

5. デプロイを検証する: Cloud Run サービスの URL にアクセスして、アプリケーションがデプロイされ、正しく機能していることを確認します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

脆弱性を修正し、CI / CD パイプラインを再デプロイします。

お疲れさまでした

これで完了です。このラボでは、ウェブ アプリケーションをビルド、スキャン、署名してクラウドにデプロイする安全な CI / CD パイプラインを実装しました。この実践経験を通じて、クラウド上で安全なアプリケーションを構築してデプロイして、セキュリティのベスト プラクティスを開発ワークフローに組み込み、ソフトウェア デリバリー プロセスの完全性を確保するために不可欠なスキルを身につけました。

次のステップと詳細情報

このラボで取り上げたトピックの詳細については、次のリソースをご確認ください。

• Binary Authorization のドキュメント
• クイックスタート: GKE を使用して Binary Authorization ポリシーを構成する
• Artifact Analysis と脆弱性スキャン

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2025 年 12 月 10 日

ラボの最終テスト日: 2024 年 9 月 4 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。