このチュートリアルでは、Google Kubernetes Engine（GKE）の Binary Authorization を設定、構成し、使用する方法について説明します。Binary Authorization は、コンテナ イメージの証明書を作成するプロセスで、GKE にイメージがデプロイされる前に特定の基準が満たされていることを確認します。
たとえば、Binary Authorization ではアプリが単体テストに合格したかどうか、またはアプリが特定のシステムセットを使用して構築されたかどうかを確認できます。詳細については、ソフトウェア デリバリー シールドの概要をご覧ください。
このチュートリアルは、コンテナの脆弱性スキャンと Binary Authorization、さらに CI / CD パイプラインでの実装と適用について理解を深めたい技術者を対象としています。
このチュートリアルは、次のトピックとテクノロジーを理解していることを前提としています。
- 継続的インテグレーションと継続的デプロイ
- 共通脆弱性識別子（CVE）の脆弱性スキャン
- GKE
- Artifact Registry
- Cloud Build
- Cloud Key Management Service（Cloud KMS）
目標
- ステージングと本番環境用に GKE クラスタをデプロイする。
- 複数の認証者と証明書を作成する。
- Cloud Build を使用して CI / CD パイプラインをデプロイする。
- デプロイ パイプラインをテストする。
- ブレークグラス プロセスを開発する。
料金
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
- Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories API を有効にします。
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories API を有効にします。
-
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。
Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
このチュートリアルのすべてのコマンドは Cloud Shell で実行されます。
CI / CD パイプラインのアーキテクチャ
ソフトウェア開発ライフサイクル（SDLC）の重要な側面は、アプリのデプロイが組織の承認済みのプロセスに従って実施されることです。これらのチェックとバランスを確立する 1 つの方法は、GKE で Binary Authorization を使用することです。まず、Binary Authorization がコンテナ イメージにメモを添付します。次に、アプリをデプロイできるようになる前に GKE が必要なメモの存在を確認します。
これらのメモ、つまり証明書は、イメージについての説明です。証明書は完全に構成可能ですが、一般的な例は次のとおりです。
- アプリが単体テストに合格した。
- アプリが品質保証（QA）チームによって検証された。
- アプリがスキャンされ、脆弱性が検出されなかった。
次の図は、既知の脆弱性がないことを確認して終了した脆弱性スキャンの後に、1 つの証明書が適用される SDLC を示しています。
このチュートリアルでは、Cloud Source Repositories、Cloud Build、Artifact Registry、GKE を使用して CI / CD パイプラインを作成します。次の図は、CI / CD パイプラインを示しています。
この CI / CD パイプラインは、次の手順で構成されます。
コンテナ イメージをアプリのソースコードでビルドします。
コンテナ イメージを Artifact Registry に push します。
Artifact Analysis は、既知のセキュリティの脆弱性または CVE についてコンテナ イメージをスキャンします。
イメージに重大度スコアが 5 を超える CVE が含まれていない場合、そのイメージは重大な CVE がないことが証明され、自動的にステージングにデプロイされます。スコアが 5 を超えると、中程度から重大な脆弱性があることを示され、証明もデプロイもされません。
QA チームがステージング クラスタ内のアプリを検査します。要件を満たしていれば、コンテナ イメージが本番環境にデプロイ可能な品質であることを示す手動の証明書を適用します。本番環境のマニフェストが更新され、アプリが本番環境用の GKE クラスタにデプロイされます。
GKE クラスタは、コンテナ イメージを調べて証明書を確認し、必要な証明書がないデプロイを拒否するように構成されています。ステージング GKE クラスタには脆弱性スキャン証明書のみが必要ですが、本番環境の GKE クラスタには脆弱性スキャンと QA 証明書の両方が必要です。
このチュートリアルでは、CI / CD パイプラインに障害を発生させ、この違反措置をテストして検証します。最後に、緊急の場合、GKE にこれらのデプロイのチェックを回避するブレークグラスの手順を実装します。
環境設定
このチュートリアルでは、次の環境変数を使用します。これらの値は要件に合わせて変更できますが、このチュートリアルのすべての手順では、これらの環境変数が存在し、有効な値が含まれているものとします。
Cloud Shell で、このチュートリアルで使用するすべてのリソースをデプロイおよび管理する Google Cloud プロジェクトを設定します。
export PROJECT_ID="${DEVSHELL_PROJECT_ID}" gcloud config set project ${PROJECT_ID}これらのリソースをデプロイするリージョンを設定します。
export REGION="us-central1"GKE クラスタと Cloud KMS 鍵はこのリージョンにあります。このチュートリアルでは、リージョンは
us-central1です。リージョンの詳細については、地域とリージョンをご覧ください。Cloud Build プロジェクト番号を設定します。
export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \ --format='value(projectNumber)')"Cloud Build サービス アカウントのメールアドレスを設定します。
export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
GKE クラスタの作成
2 つの GKE クラスタを作成し、Cloud Build が GKE にアプリをデプロイするための Identity and Access Management（IAM）権限を付与します。GKE クラスタの作成には数分かかることがあります。
Cloud Shell で、ステージング用の GKE クラスタを作成します。
gcloud container clusters create "staging-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE本番環境の GKE クラスタを作成します。
gcloud container clusters create "prod-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCECloud Build サービス アカウントに GKE にデプロイする権限を付与します。
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/container.developer"
署名鍵の作成
証明書に署名するための Cloud KMS 非対称鍵を 2 つ作成します。
Cloud Shell で、
binauthzという名前の Cloud KMS キーリングを作成します。gcloud kms keyrings create "binauthz" \ --project "${PROJECT_ID}" \ --location "${REGION}"脆弱性スキャン証明書の署名と検証に使用する
vulnz-signerという名前の非対称 Cloud KMS 鍵を作成します。gcloud kms keys create "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"qa-signerという名前の非対称 Cloud KMS 鍵を作成し、QA 証明書に署名して検証します。gcloud kms keys create "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"
証明書の構成
コンテナ イメージに添付するメモを作成し、Cloud Build サービス アカウントに、メモの表示、メモの添付、および前の手順で作成した鍵を使用した認証者の作成を行う権限を付与します。
脆弱性スキャナの証明書を作成する
Cloud Shell で、
vulnz-noteという名前の Artifact Analysis メモを作成します。curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/vulnz-note", "attestation": { "hint": { "human_readable_name": "Vulnerability scan note" } } } EOFCloud Build サービス アカウントに、
vulnz-noteメモを表示したり、コンテナ イメージに添付したりする権限を付与します。curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/vulnz-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOF脆弱性スキャン認証者を作成します。
gcloud container binauthz attestors create "vulnz-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "vulnz-note" \ --description "Vulnerability scan attestor"認証者の署名鍵の公開鍵を追加します。
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "vulnz-attestor" \ --keyversion "1" \ --keyversion-key "vulnz-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"Cloud Build サービス アカウントに、
vulnz-attestorによって作成された証明書を閲覧する権限を付与します。gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"Cloud Build サービス アカウントに、
vulnz-signer鍵を使用してオブジェクトへ署名する権限を付与します。gcloud kms keys add-iam-policy-binding "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role 'roles/cloudkms.signerVerifier'
QA 証明書を作成する
Cloud Shell で、
qa-noteという名前の Artifact Analysis メモを作成します。curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/qa-note", "attestation": { "hint": { "human_readable_name": "QA note" } } } EOFCloud Build サービス アカウントに、
qa-noteメモを表示したり、コンテナ イメージに添付したりする権限を付与します。curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/qa-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOFQA 認証者を作成します。
gcloud container binauthz attestors create "qa-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "qa-note" \ --description "QA attestor"認証者の署名鍵の公開鍵を追加します。
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "qa-attestor" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"Cloud Build サービス アカウントに、
qa-attestorによって作成された証明書を閲覧する権限を付与します。gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"QA チームに証明書に署名する権限を付与します。
gcloud kms keys add-iam-policy-binding "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "group:qa-team@example.com" \ --role 'roles/cloudkms.signerVerifier'
Binary Authorization ポリシーの設定
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE で GKE クラスタを作成しても、バイナリがクラスタで実行するために必要な証明書を GKE に指示するポリシーを作成する必要があります。Binary Authorization ポリシーはプロジェクト レベルで存在しますが、クラスタレベルの構成が含まれています。
次のポリシーは、デフォルトのポリシーを次のように変更します。
デフォルトの
evaluationModeをALWAYS_DENYに変更します。除外されたイメージ、または必要な証明書があるイメージのみがクラスタで実行できます。globalPolicyEvaluationModeを有効にします。これにより、デフォルトの許可リストが Google 提供のシステム イメージのみを含むように変更されます。次のクラスタ アドミッション ルールを定義します。
staging-clusterにはvulnz-attestorからの証明書が必要です。prod-clusterにはvulnz-attestorとqa-attestorからの証明書が必要です。
Binary Authorization ポリシーの詳細については、ポリシー YAML リファレンスをご覧ください。
Cloud Shell で、Google Cloud プロジェクトの Binary Authorization ポリシーを記述する YAML ファイルを作成します。
cat > ./binauthz-policy.yaml <<EOF admissionWhitelistPatterns: - namePattern: docker.io/istio/* defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_DENY globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: # Staging cluster ${REGION}.staging-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor # Production cluster ${REGION}.prod-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor - projects/${PROJECT_ID}/attestors/qa-attestor EOF新しいポリシーを Google Cloud プロジェクトにアップロードします。
gcloud container binauthz policy import ./binauthz-policy.yaml \ --project "${PROJECT_ID}"
脆弱性スキャン チェッカーの作成と API の有効化
Cloud Build でビルドステップとして使用されるコンテナ イメージを作成します。このコンテナは、検出された脆弱性の重大度スコアを構成済みのしきい値と比較します。スコアがしきい値内の場合、Cloud Build はコンテナに証明書を作成します。スコアがしきい値を外れた場合、ビルドは失敗し、証明書は作成されません。
Cloud Shell で、認証者イメージを保存する新しい Artifact Registry リポジトリを作成します。
gcloud artifacts repositories create cloudbuild-helpers \ --repository-format=DOCKER --location=${REGION}Binary Authorization ツールとサンプル アプリケーション ソースのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools脆弱性スキャン認証者の
attestorというコンテナをビルドして、cloudbuild-helpersArtifact Registry に push します。gcloud builds submit \ --project "${PROJECT_ID}" \ --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \ ~/binauthz-tools
Cloud Build パイプラインの設定
サンプルアプリと Kubernetes マニフェストの Cloud Source Repositories リポジトリと Cloud Build トリガーを作成します。
hello-app の Cloud Source Repositories と Artifact Registry リポジトリを作成する
Cloud Shell で、サンプルアプリの Cloud Source Repositories のリポジトリを作成します。
gcloud source repos create hello-app \ --project "${PROJECT_ID}"リポジトリのクローンをローカルに作成します。
gcloud source repos clone hello-app ~/hello-app \ --project "${PROJECT_ID}"サンプルコードをリポジトリにコピーします。
cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-appアプリケーション イメージを保存する新しい Artifact Registry リポジトリを作成します。
gcloud artifacts repositories create applications \ --repository-format=DOCKER --location=${REGION}
hello-app の Cloud Build トリガーを作成する
Google Cloud コンソールの [トリガー] ページに移動します。
[リポジトリの管理] をクリックします。
hello-appリポジトリの [...] をクリックし、[トリガーを追加] を選択します。[トリガー設定] ウィンドウに、次の詳細を入力します。
- [名前] フィールドに「
build-vulnz-deploy」と入力します。 - [イベント] で [ブランチに push する] を選択します。
- [リポジトリ] フィールドで、メニューから
hello-appを選択します。 - [ブランチ] フィールドに「
master」と入力します。 - [構成] で [Cloud Build 構成ファイル（YAML または JSON）] を選択します。
- [ロケーション] で、[リポジトリ] を選択してデフォルト値
/cloudbuild.yamlを入力します。
- [名前] フィールドに「
次の代入変数のペアを追加します。
_COMPUTE_REGIONと値us-central1（または最初に選択したリージョン）。_KMS_KEYRINGと値binauthz。_KMS_LOCATIONと値us-central1（または最初に選択したリージョン）。_PROD_CLUSTERと値prod-cluster。_QA_ATTESTORと値qa-attestor。_QA_KMS_KEYと値qa-signer。_QA_KMS_KEY_VERSIONと値1。_STAGING_CLUSTERと値staging-cluster。_VULNZ_ATTESTORと値vulnz-attestor。_VULNZ_KMS_KEYと値vulnz-signer。_VULNZ_KMS_KEY_VERSIONと値1。
[作成] をクリックします。
Cloud Build パイプラインをテストする
サンプルアプリを Cloud Source Repositories のリポジトリに commit して push し、CI / CD パイプラインをテストします。Cloud Build は変更を検出し、アプリをビルドして staging-cluster にデプロイします。パイプラインは QA 検証のために最大 10 分間待機します。QA チームによってデプロイが検証された後、プロセスは続行され、本番環境用 Kubernetes マニフェストが更新され、Cloud Build によってアプリが prod-cluster にデプロイされます。
Cloud Shell で、
hello-appファイルを Cloud Source Repositories リポジトリに commit して push し、ビルドをトリガーします。cd ~/hello-app git add . git commit -m "Initial commit" git push origin masterGoogle Cloud コンソールの [履歴] ページに移動します。
ビルドの進捗状況を確認するには、Cloud Build の最新の実行をクリックします。
staging-clusterへのデプロイが終了したら、[サービス] ページに移動します。アプリが機能していることを確認するには、アプリの [エンドポイント] リンクをクリックします。
[リポジトリ] ページに移動します。
applicationsをクリックします。hello-appをクリックします。ステージング デプロイで検証したイメージをクリックします。
イメージの詳細から [ダイジェスト] の値をコピーします。この情報は次のステップで必要となります。
手動の QA 証明書を適用するために、
...を、イメージの詳細からコピーした値に置き換えます。DIGEST変数はsha256:hash-valueの形式にします。Await QA attestationビルド手順では、以下に示すコピーペースト可能なコマンドも出力されます。DIGEST="sha256:..." # Replace with your value gcloud beta container binauthz attestations sign-and-create \ --project "${PROJECT_ID}" \ --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \ --attestor "qa-attestor" \ --attestor-project "${PROJECT_ID}" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-location "${REGION}" \ --keyversion-keyring "binauthz" \ --keyversion-project "${PROJECT_ID}"アプリがデプロイされたことを確認するには、[サービス] ページに移動します。
アプリを表示するには、エンドポイント リンクをクリックします。
未検証のイメージのデプロイ
これまでのところ、サンプルアプリに脆弱性はありません。アプリを更新して別のメッセージを出力し、ベースイメージを変更します。
Cloud Shell で、出力を
Hello WorldからBinary Authorizationに変更し、ベースイメージをdistrolessからdebianに変更します。cd ~/hello-app sed -i "s/Hello World/Binary Authorization/g" main.go sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile変更を commit して push します。
git add . git commit -m "Change message and base image" git push origin masterCI / CD パイプラインのステータスをモニタリングするには、Google Cloud コンソールの [履歴] ページに移動します。
イメージに CVE が検出されたため、ビルドは失敗します。
検出された CVE を調べるには、[イメージ] ページに移動します。
hello-appをクリックします。検出された CVE を確認するには、最新のイメージの脆弱性の概要をクリックします。
Cloud Shell で、脆弱性スキャンによる証明書がない新しいイメージを本番環境にデプロイしてみます。
export SHA_DIGEST="[SHA_DIGEST_VALUE]" cd ~/hello-app sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \ sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \ sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml gcloud container clusters get-credentials \ --project=${PROJECT_ID} \ --region="${REGION}" prod-cluster kubectl apply -f kubernetesGoogle Cloud コンソールの [ワークロード] ページに移動します。
イメージに
vulnz-attestorとqa-attestorの署名がないため、デプロイに失敗しました。
ブレークグラスの手順
場合によっては、通常のワークフローの範囲外の変更を許可する必要があります。必要な証明書がないイメージのデプロイを許可するために、ポッド定義には、ブレークグラス ポリシーフラグによるアノテーションが付けられています。このフラグを有効にすると、GKE は引き続き必要な証明書を確認しますが、コンテナ イメージのデプロイが許可され、違反が記録されます。
証明書チェックの回避の詳細については、ポリシーをオーバーライドするをご覧ください。
Cloud Shell で、Kubernetes マニフェストのブレークグラス アノテーションのコメントを解除します。
sed -i "31s/^#//" kubernetes/deployment.yamlkubectlを使用して変更を適用します。kubectl apply -f kubernetes変更が
prod-clusterにデプロイされたことを確認するには Google Cloud コンソールの [ワークロード] ページに移動します。デプロイのエラー メッセージが消えました。
アプリがデプロイされたことを確認するには、[サービス] ページに移動します。
アプリを表示するには、エンドポイント リンクをクリックします。
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
プロジェクトの削除
- Google Cloud コンソールで、[リソースの管理] ページに移動します。
- プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
- ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。
次のステップ
- コンテナ構築のおすすめの方法。
- コンテナ化されたウェブ アプリケーションのデプロイ。
- Cloud Build を使用した GitOps スタイルの継続的デリバリー。
- マネージド ベースイメージ。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。