Workload Identity 連携と Terraform Cloud でインフラストラクチャを管理する
Google Cloud Japan Team
※この投稿は米国時間 2023 年 9 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。
はじめに
Terraform Cloud（TFC）は、大企業による Infrastructure as Code（IaC）開発の管理を支援します。Google Cloud プロジェクトの数が増えるにつれて、Terraform Cloud プロジェクトやワークスペースに関するアクセス制御の管理がより複雑になる場合があります。ですが心配はいりません。Google は、Google Cloud サービス アカウント キーを上回る安全性を確保できるソリューションを用意しています。このソリューションは、何百どころか何千もの Google Cloud プロジェクト、TFC ワークスペース、TFC プロジェクトに適合するよう、Workload Identity 連携を使用したスケーリングが可能です。
ある企業のシナリオ
架空の金融サービス企業 example.com について考えてみましょう。この企業はバンキング、融資、保険、仲介業サービスを顧客に提供しています。同社の Google Cloud リソース階層は、ビジネス ユニット > 環境フォルダ > アプリケーション プロジェクトとなっています。
IaC コードベースが増大して組織全体のインフラストラクチャを管理するようになると、大規模な数のデプロイ パイプラインのアクセス制御が困難になります。以下のソリューション ガイダンスでは、次に示す 3 つの課題に対処しています。
- 本番環境ではなく開発環境でのみリソースの作成や削除を行う開発 IaC コードにしたい。
- 仲介業ビジネス ユニットのリソースが、バンキング IaC コードによって誤って作成または削除されないようにしたい。
- TFC プロジェクト、ワークスペース、Google Cloud Workload Identity プール、Terraform 用サービス アカウントについて、自社のユースケースに最適な数を知りたい。
ソリューション アーキテクチャ
大まかな流れは次のとおりです。Terraform Cloud ワークスペースと Workload Identity 連携のインテグレーションによって、Google Cloud の認証を行い、Google Cloud サービス アカウントの権限を借用できます。この権限借用によって、アプリケーション プロジェクトでより安全にリソースを管理できます。適切なサービス アカウントから権限を借用する許可が TFC ワークスペースに与えられています。
同ワークスペースが操作するコンポーネントや操作方法について、以下の図に示します。
このソリューションを導入するには、Terraform Cloud と Google Cloud で以下の設定を行う必要があります。
Terraform Cloud の設定
- ビジネス ユニットごとに 1 件の TFC プロジェクトを作成します。
- TFC プロジェクト配下にワークスペースを作成します。（各環境に 1 件）
- 動作させるデプロイ パイプラインに適切なプール ID で TFC ワークスペースを構成します。
Google Cloud の設定
Google Cloud において、TFC ワークスペース用の Workload Identity プールとサービス アカウントは以下の手順で設定します。
- Workload Identity プールを設定します。
a. 各環境ごとに 1 件の Workload Identity プールを作成します。
b. Workload Identity プール プロバイダとして Terraform Cloud を作成します。
2. リソース管理用サービス アカウントを設定します。
a. Terraform ワークスペースの権限を借用するためのサービス アカウント（TF サービス アカウント）を作成します。
b. アプリケーション プロジェクト内で IaC を実行するために最低限必要なロールを、最小権限の原則に準拠したうえで TF サービス アカウントに付与します。
3. TF サービス アカウント権限の借用許可は、1 つの TFC ワークスペースに限定して付与します。
3. IAM とセキュリティ トークン サービス（STS）のデータアクセス ログを有効化し、監査やトラブルシューティングで利用できるようにします。
Workload Identity プールを使用して Google Cloud の認証を行い、サービス アカウントの権限を借用して Google Cloud リソースを管理します。キーなしの認証の詳細については、Google のブログ記事 GitHub Actions からのキーなしの認証の有効化と GitHub Actions と Terraform Cloud に対応した Workload Identity 連携の構成を参照してください。
すべてを組み合わせる
以下の例は、プロジェクト「prj-banking-1-prod」でリソース管理を行う IaC コード「banking-prod」を示しています。
プラン実行が成功した場合には次のようになります。
Terraform Cloud 内のプロジェクトとワークスペース
Terraform Cloud 内の IaC コードについては、管理を簡単にするためにプロジェクトとワークスペースでまとめています。今回の例では、バンキング、保険、仲介業、融資という 4 件のプロジェクトを、それぞれのビジネス ユニットに対して 1 つずつ作成しました。
Terraform ワークスペースのアクセス制御
TFC ワークスペースにアクセスするには、適切なロールベース アクセス制御および承認プロセスが <ビジネス ユニット>-<環境> という命名規則に沿って構築されていることを確認し、アクセス権を得ようとしている Workload Identity プールを環境から特定できるようにします。たとえば、「banking-prod」は Google Cloud 内の「terraform-pool-prod」へのアクセス権を得ています。
Terraform ワークスペースの構成
以下の構成例では、ワークスペース「banking-prod」用の本番環境プール プロバイダに接続しています。このステップは、Google Cloud の設定完了後に実施します。
Workload Identity プール管理
Workload Identity プールは、外部 ID の管理を可能とする Google Cloud 内エンティティです。各環境には、それぞれ独自の Workload Identity プールを備える必要があります。厳格な IAM ポリシーをプール プロジェクトに設定して、承認されたユーザーのみがアクセス権を得られるようにします。
以下のプールは、example.com の組織ユースケースにあわせて作成しています。
以下の IaC コードは、単一の TFC プロバイダを内部に備える 1 つの Identity プールの作成について示しています。
プール プロバイダは、Google Cloud 属性にマッピングされた TFC OIDC アサーションを使用して作成しています。TFC ID トークンがサポートしているクレームについては、https://app.terraform.io/.well-known/openid-configuration を参照してください。
IaC コードで作成したプロバイダ構成を、以下の図で示します。
Workload Identity プールのセキュリティ
Terraform Identity プール プロバイダのリソースを構成して属性条件を使用することで、example.com Workload Identity プールの使用を、example.com TFC 組織および特定の単一環境に制限します。
TFC ワークスペースに対する不正アクセスを拒否する
- ワークスペースによる Workload Identity プールに対する不正アクセスは拒否されます。
本番環境のプールを使用した、開発 TFC ワークスペース構成
TFC で Terraform プランを実行した際に発生したエラー
- ワークスペースによるサービス アカウントに対する不正アクセスは拒否されます。
本番環境のサービス アカウントを使用した、開発 TFC ワークスペース構成
Terraform プランを実行した際に発生したエラー
サービス アカウント管理
- アプリケーション プロジェクト内で Google Cloud リソースを管理するために Terraform Cloud ワークスペースで使用する Google Cloud サービス アカウントを作成します。今回の企業ユースケースでは、TFC ワークスペースごとに異なるサービス アカウントを作成しました。
- これらのサービス アカウントは、適切な IAM を適用した個々の Google Cloud プロジェクトで作成します。
TFC ワークスペース「banking-dev」にのみ権限の借用許可を与えた例を、以下に示します。
- アプリ プロジェクトの要件に基づき、必要最低限のロールをサービス アカウントに付与します。たとえば、サービス アカウント「sa-tf-banking-prod」に対して roles/storage.admin や roles/compute.admin を付与して、プロジェクト「prj-banking-1-prod」内で Compute サービスや Cloud Storage サービスを管理できるようにします。
サービス アカウント「sa-tf-banking-prod」を使用する「prj-banking-1-prod」の IAM は、以下のようになります。
監査可能性
プール プロジェクトで IAM と STS のデータアクセス ログを有効化することで、それらのプロジェクト内にあるリソースに誰がアクセスしているのかや、アクセスされている具体的なリソースについて追跡し、不正アクセスを特定できるようにします。
IAM と STS のログエントリ例:
今すぐ使用を開始する
Workload Identity 連携の使用に関するコンセプトやベスト プラクティスを詳細に説明した以下のドキュメントを参照してください。
- Workload Identity 連携 | IAM ドキュメント | Google Cloud
- デプロイメント パイプラインとの Workload Identity 連携を構成する | IAM ドキュメント | Google Cloud
- Workload Identity 連携の使用に関するベスト プラクティス | IAM ドキュメント | Google Cloud
- パイプラインでサービス アカウントを使用するためのベスト プラクティス | IAM ドキュメント | Google Cloud
- Google Cloud、クラウド インフラストラクチャ エンジニア Manjuram Perumalla
