Google Cloud Workload Identity Federationのセットアップ

このページでは、Workload Identity Federation を使用して Aikido に GCP プロジェクトへのアクセスを付与する方法を説明します。もう一つの方法はサービスアカウントを使用することです。

Google Cloud Workload Identity Federation（WIF）を使用すると、サービスアカウントキーやその他のシークレットを使わずに、Aikido に Google Cloud プロジェクトをスキャンさせることができます。

Workload Identity Federation のプールとプロバイダを設定することで、Aikido は自身の固有の認証情報を、お客様の GCP 環境で有効な認証情報と交換できるようになります。これらの認証情報は有効期間が短く、どこにも保存されないため、この方法ははるかに安全であり、さまざまなコンプライアンス要件にも準拠しています。

WIF の詳細については、Google Cloud のドキュメントをご覧ください。

Workload Identity Federation を使う理由

長期間有効なサービスアカウントキーが不要になります。
キーのローテーションとシークレット管理が簡素化されます。
より厳格なコンプライアンスおよびセキュリティ要件を満たします。

はじめに

Workload Identity Federation は、Google Cloud オンボーディングウィザードの「Configure Access」ステップでオプションとして利用できます。

Aikido の GCP オンボーディングで Service Account と Workload Identity Federation のどちらかを選択する

Aikido は、Google Cloud プロジェクトでワークロード ID プールとプロバイダをセットアップするために必要な CLI コマンドを提供します。

他の方法で WIF を設定したい場合は、以下の詳細情報が必要になります。

プロバイダの詳細

これらの値は、アプリ内で Aikido が提供する CLI コマンドから取得することを強くお勧めします。

プロバイダ: AWS（これにより Aikido は AWS IAM 認証情報を GCP 認証情報と交換できます）
AWS アカウント ID: 881830977366（Aikido が認証情報の交換を開始する AWS アカウントです）
属性マッピング（AWS のデフォルトマッピングである必要があります）:
- google.subject = assertion.arn
- attribute.aws_role = assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

IAM 権限

Aikido AWS アカウントのすべてのプリンシパルではなく、アクセスを必要とする特定の Aikido IAM ロールのみにアクセスを付与します。

Aikido IAM ロールのプリンシパルは次のように組み立てます。

principalSet://iam.googleapis.com/projects/ + <your_project_number> + /locations/global/workloadIdentityPools/ + <your_wif_pool> + /attribute.aws_role/arn:aws:sts:: + <aikido_aws_account_id> + :assumed-role/ + <aikido_aws_role_name>

Aikido には、プロジェクトまたは組織レベルで以下の権限が必要です。

Aikido ロール lambda-gcp-cloud-findings-role-1muvqxle に対する Viewer/Reader（利用可能な場合は Reader を推奨）および Security Reviewer。
Artifact Registry Viewer:
- Aikido に Artifact Registry のコンテナイメージをスキャンさせたい場合は、Aikido ロール lambda-container-image-scanner-role-pb0qotst に付与します。
- または、Aikido に Artifact Registry Vulnerability Scanning の検出結果のみを取り込ませたい場合は、Aikido ロール lambda-gcp-cloud-findings-role-1muvqxle に付与します。

プロジェクトまたは組織の IAM ポリシーにすでに条件付きバインディングが含まれている場合、gcloud ではすべての新しいバインディングで条件を明示的に指定する必要があります。

Aikido 用の IAM バインディングを適用する際は、必ず条件を明示的に無効化してください。これは、gcloud コマンドに --condition=None を追加するか、CLI でプロンプトが表示されたときに None を選択することで行えます。

Workload Identity Federation のプールとプロバイダ、および IAM 権限の設定が完了したら、Aikido にアップロードする構成ファイルを生成します。推奨される、よりシンプルな方法は（サービスアカウントの権限借用ではなく）直接アクセスです。

App Engine をスキャンする場合は、直接アクセスではなくサービスアカウントの権限借用を使用してください。App Engine の Google Cloud API は直接 WIF アクセスをサポートするサービスの一覧に含まれていないため、直接アクセスでは認証エラーで失敗します。サービスアカウントの権限借用および下記の FAQ を参照してください。

よくある質問

すでに接続済みの GCP プロジェクトをサービスアカウントから WIF に移行できますか？

はい。アプリ内の手順に従ってプロジェクトに WIF を設定し、オンボーディングを完了する代わりに、生成した構成ファイルで接続済みの GCP プロジェクトの認証情報を更新してください。

既存の WIF プールを使用できますか？

はい、既存の WIF プールのいずれかに新しいプロバイダを追加できます。CLI コマンドを調整して、既存のプールの名前を使用する必要があります。

WIF プロバイダに属性条件も設定すべきですか？

（WIF プール全体ではなく）特定の Aikido プリンシパルのみにアクセスを付与しているため、属性条件の重要性は低くなります。ただし、ポリシーで義務付けられている場合は、上記の 2 つの IAM ロールに対して条件を追加できます。

直接アクセスではなく、サービスアカウントの権限借用でアクセスを設定できますか？

はい。ただし、直接アクセスの方がシンプルです。組織ですべての外部 ID がサービスアカウントを介して動作することが義務付けられている場合や、App Engine をスキャンする場合（その API は直接 WIF アクセスをサポートしていないため）は、権限借用を使用してください。サービスアカウントを作成し、上記の Aikido プリンシパルがそれを借用できるようにし（roles/iam.workloadIdentityUser）、必要な IAM 権限を付与して、サービスアカウント用の構成ファイルを生成します。

これ用の Terraform モジュールはありますか？

はい！こちらで入手できます: https://github.com/AikidoSec/gcp-onboarding-terraform-module。プロジェクトのオンボーディングと組織のオンボーディングの 2 つのバリエーションがあります。