ランタイムセキュリティ分析情報

1. はじめに

このラボでは、Cloud Run と GKE クラスタにアプリケーションをデプロイし、Software Delivery Shield でデプロイのセキュリティ分析情報を表示します。

学習内容

Artifact Registry のセキュリティ分析情報
Cloud Run のセキュリティ分析情報
GKE Security Posture

2. 設定と要件

Cloud プロジェクトのセットアップ

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 米ドル分の無料トライアルプログラムをご利用いただけます。

環境設定

検索バーの右にあるアイコンをクリックして、Cloud Shell をアクティブにします。

Cloud Shell から、このラボに必要な API を有効にします。

gcloud services enable run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  container.googleapis.com \
  containersecurity.googleapis.com

承認を求められたら、[承認] をクリックして続行します。

成功すると次のようなメッセージが表示されます。

Operation "operations/acf.p2-327036483151-73d90d00-47ee-447a-b600-a6badf0eceae" finished successfully.

コマンドを実行して、GKE クラスタを非同期で作成します。これはラボで後ほど使用します。

gcloud beta container clusters create gke-cluster \
    --zone us-central1-a \
    --async

3. アプリケーションを準備する

まず、HTTP リクエストに応答するシンプルな Express ベースの Node.js アプリケーションを準備します。

Cloud Shell で、starter-nodejs という名前の新しいディレクトリを作成し、そのディレクトリに移動します。

mkdir starter-nodejs
cd starter-nodejs

次のコマンドを実行して、package.json ファイルを作成します。

cat > ./package.json << EOF
{
  "name": "cloudrun-starter-app",
  "version": "1.0.0",
  "description": "Node.js Starter Application",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^4.18.2"
  }
}
EOF

上記のファイルで特に重要なのは、start スクリプトのコマンドと、Express ウェブアプリケーションフレームワークへの依存関係が含まれている点です。

次に、同じディレクトリで次のコマンドを実行して index.js ファイルを作成します。

cat > ./index.js << EOF
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  console.log('Received a request.');
  res.send("Hello Cloud Run!");
});

const port = process.env.PORT || 8080;

app.listen(port, () => {
  console.log('Listening on port', port);
});
EOF

このコードは、PORT 環境変数で定義されたポートをリッスンする基本的なウェブサーバーを作成します。これでアプリは完成しました。このアプリをコンテナ化してデプロイします。

4. Cloud Run アプリケーションをデプロイする

次のコマンドを実行して、アプリケーションをデプロイします。

gcloud run deploy starter-app \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --max-instances=3

Artifact Registry リポジトリの作成を確認します。

Deploying from source requires an Artifact Registry Docker repository to store built containers. A repository named [cloud-run-source-deploy] in region [us-central1] will be created.

Do you want to continue (Y/n)? y

5. Artifact Registry と Cloud Build のセキュリティ分析情報

ビルドが完了するまでに数分かかります。

Cloud Build を開き、最新のビルドのビルドアーティファクトを確認します。

Google Cloud コンソールの Cloud Build UI には、Software Delivery Shield の [セキュリティ分析情報] パネルがあります。このパネルには、SLSA レベル、依存関係における脆弱性、ビルドの来歴など、ビルドに関連するセキュリティ情報が表示されます。

作成したコンテナイメージのセキュリティ分析情報を確認します。スキャンされたアーティファクトのリンクをクリックして、Artifact Registry でこのイメージの脆弱性の詳細を表示します。

Cloud Shell コンソールに戻り、Cloud Run アプリケーションのデプロイが完了したことを確認します。

Done.
Service [starter-app] revision [starter-app-00001-maw] has been deployed and is serving 100 percent of traffic.
Service URL: https://starter-app-nin5jpgefq-uc.a.run.app

6. Cloud Run のセキュリティ分析情報

Cloud Run には、SLSA ビルドレベルのコンプライアンス情報、ビルドの来歴、実行中のサービスで見つかった脆弱性などのソフトウェアサプライチェーンのセキュリティ分析情報を表示するセキュリティパネル（プレビュー）が含まれています。

Cloud Run を開き、[REVISIONS / SECURITY] タブでセキュリティ分析情報を確認します。

このパネルには、次の情報が表示されます。

ID と暗号化: デプロイに使用されるデフォルトの Compute Engine サービスアカウントのメールアドレスと暗号鍵です。
SLSA レベル: このビルドは SLSA レベル 3 です。これは、SLSA 仕様に従ってソフトウェアビルドプロセスの成熟度を示します。
脆弱性: アプリケーションの依存関係に見つかった脆弱性。
ビルドの詳細: ビルダーやログを表示するためのリンクなど、ビルドの詳細。
ビルドの来歴: ビルドの来歴。ビルドに関する検証可能なメタデータのコレクションです。これには、ビルドされたイメージのダイジェスト、入力ソースの場所、ビルドツールチェーン、ビルドステップ、ビルド時間などの詳細情報が含まれます。

7. GKE Security Posture

GKE は、コンテナのセキュリティポスチャーを評価し、クラスタ設定、ワークロード構成、脆弱性に関する積極的なガイダンスを提供します。これには、GKE クラスタとワークロードをスキャンして、セキュリティ対策を改善するために活用できる独自の推奨事項を提供するセキュリティポスチャーダッシュボード（プレビュー）が含まれています。

次の手順では、アプリケーションを GKE クラスタにデプロイし、GKE セキュリティポスチャーダッシュボードでセキュリティ分析情報を確認します。

次のコマンドを実行して、クラスタの準備ができていることを確認します。

gcloud beta container clusters list

出力例:

NAME: gke-cluster
LOCATION: us-central1-a
MASTER_VERSION: 1.24.9-gke.3200
MASTER_IP: 34.29.226.228
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.24.9-gke.3200
NUM_NODES: 3
STATUS: RUNNING

GKE クラスタの認証情報と構成を取得します。

gcloud container clusters get-credentials gke-cluster  \
    --region=us-central1-a

前のステップでビルドしたイメージを使用してアプリケーションをデプロイするコマンドを実行します。

export PROJECT_ID=$(gcloud config get-value project)

kubectl run starter-app \
  --image us-central1-docker.pkg.dev/${PROJECT_ID}/cloud-run-source-deploy/starter-app:latest \
  --port 8080

GKE ワークロードには、攻撃対象領域を制限する、強化された構成を含めることが理想的です。クラスタ全体のワークロードの確認では、構成の問題がないか手動で確認するのが難しい場合があります。セキュリティポスチャーダッシュボードを使用すると、複数のクラスタにまたがって実行されているワークロードの構成を自動的にスキャンし、実用的なスコア付きの結果と推奨事項を確認でき、セキュリティポスチャーを強化することができます。

ワークロード構成スキャンを有効にします。

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-config-audit

ワークロード構成のスキャンに加えて、ワークロードの脆弱性スキャンを有効にして、セキュリティポスチャーダッシュボードで結果を確認することもできます。セキュリティポスチャーダッシュボードは、GKE クラスタとワークロードのセキュリティを強化するための独自の情報と推奨事項を提供する一連の機能です。

GKE は、GKE クラスタで実行されている対象のすべての Pod のコンテナイメージを自動的にスキャンし、NIST などの公開 CVE データベースの脆弱性データを使用して既知の脆弱性を検出します。

コンテナイメージで脆弱性が見つかった場合、GKE は重大度を割り当て、Google Cloud コンソールの [セキュリティポスチャー] ダッシュボードに結果を表示します。また、GKE は監査とトレーサビリティのために Cloud Logging にもエントリを追加します。

ワークロードの脆弱性スキャンを有効にします。

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-vulnerability-scanning \
    --async

GKE の [セキュリティポスチャー] ページを開きます。

ワークロード監査が完了するまで数分待ってから、結果を確認します。

構成の問題と影響を受けるワークロードを確認します。

[Security Posture] ダッシュボードを使用する理由

セキュリティポスチャーダッシュボードは、有効な GKE クラスタに対して有効にできる基本的なセキュリティ対策です。Google Cloud では、次の理由から、すべてのクラスタでセキュリティポスチャーダッシュボードを使用することをおすすめします。

中断を最小限に抑える: 機能によって、実行中のワークロードを妨げられることや中断されることはありません。
実行可能な推奨事項: ある場合は、検出された懸案事項を解決するためのアクションアイテムがセキュリティポスチャーダッシュボードで提供されます。これらのアクションには、実行できるコマンド、行う構成変更の例、脆弱性を軽減するためのアドバイスが含まれます。
可視化: セキュリティポスチャーダッシュボードは、プロジェクト全体のクラスタに影響を及ぼす懸念事項の概要を可視化し、進捗状況と各懸念事項の潜在的な影響を示すチャートとグラフを含みます。
スコア付き結果: GKE は、Google のセキュリティチームと業界基準の専門知識に基づいて、発見された懸念事項に重大度評価を割り当てます。
監査可能なイベントログ: GKE は、検出されたすべての懸念事項を Logging に追加して、レポート機能とオブザーバビリティを向上させます。

8. 完了

おめでとうございます！この Codelab は終了です。

学習した内容

Cloud Run と GKE で実行されているビルドアーティファクトとアプリケーションのセキュリティ分析情報

クリーンアップ

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

プロジェクトの削除

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

—

最終更新日: 2023 年 3 月 21 日