Ctrlk
Changelog NotificationsAPIAikido login
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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 のオンボーディングウィザードの「アクセスを構成」ステップで選択肢として利用できます。

Aikido の GCP オンボーディングで Service Account と Workload Identity Federation を選ぶ場合

Aikido が、Google Cloud プロジェクトで workload identity pool と provider をセットアップするために必要な 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_acocunt_id> + :assumed-role/ + <aikido_aws_role_name>

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

  • Viewer/Reader （利用可能であれば Reader を推奨）および セキュリティ レビュー担当者 Aikido ロール用の lambda-gcp-cloud-findings-role-1muvqxle.

  • Artifact Registry Viewer 対象:

    • Aikido ロールに対して、Aikido に Artifact Registry のコンテナイメージをスキャンさせたい場合 lambda-container-image-scanner-role-pb0qotst.

    • または、Aikido ロールに対して、Artifact Registry Vulnerability Scanning からの検出結果のみを Aikido に取り込みたい場合 lambda-gcp-cloud-findings-role-1muvqxle.

プロジェクトまたは組織の IAM ポリシーにすでに 条件付きバインディング, gcloud は、新しいバインディングすべてに条件を明示的に指定することを要求します。

Aikido 用の IAM バインディングを適用する際は、 条件を明示的に無効にすることを忘れないでください。これには、 --condition=None を gcloud コマンドを追加するか、CLI によって求められたときに なし を選択します。

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

直接アクセスを使用した Google Cloud WIF 設定ファイルの生成

FAQ

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

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

  • 既存の WIF プールを使えますか？

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

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

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

  • 直接ではなく、サービスアカウントのインパーソネーション経由でアクセスを構成できますか？

はい。ただし、直接アクセスのほうが簡単です。組織の方針で、すべての外部 ID がサービスアカウント経由で動作することが義務付けられている場合は、インパーソネーションを使用してください。サービスアカウントを作成し、上記の Aikido プリンシパルにそれを偽装することを許可し（roles/iam.workloadIdentityUser）、必要な IAM 権限を付与し、サービスアカウント用の設定ファイルを生成できます。

サービスアカウント用の設定ファイルの生成

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

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

最終更新

役に立ちましたか？