Google FormsとTerraformを使ってGCPプロジェクトを自動作成するシステムを構築してみた その③
投稿者：今井
初めに
こんにちは、CI部の今井です。
今年もアドベントカレンダーの季節がやってきましたね。(3回目)
今回、私が書いているこの記事はNI+C AdventCalendar GCP/GWS Team 2022 Advent Calendar 2022の12日目の記事となります。
本記事では「GCPプロジェクトの作成」をいろいろなサービスを組み合わせて自動化したことをお話しさせていただければと思います。
その①とその②では、どういったサービスを選択したかろ利用したコード等のお話をさせていただきました。
今回のその③はその②のブログを書いておりまして、長くなりすぎてしまったので分割したGCPでの設定内容をお話しさせていただきます。
一部内容が薄くなってしまうところがあるかと思いますが、ご容赦いただけますと幸いです。
GCPプロジェクトの自動化システムについて
今回作成したシステムはその①でも示した通り以下の画像のようなものとなっています。
このシステムの中でのGCPプロジェクト「ci-project-builder-pj」の役割としては大きく2つで、プロジェクトを作成することと各プロジェクトのステートを持つことになります。
プロジェクトの作成自体はサービスアカウントが実施しており、付与している権限は以下の2つとなります。
- プロジェクト作成者(roles/resourcemanager.projectCreator)
- 請求先アカウント ユーザー(roles/billing.user)
プロジェクト作成者は組織での権限付与、請求先アカウントユーザーはもし請求先アカウントをプロジェクト作成時に設定する場合の権限付与となります。
必須はプロジェクト作成者権限のみとなります。
このサービスアカウントのアドレスはGitLab CICDの中のVariablesにて設定するようにしてください。
Workload Identity
GCPプロジェクトと外部サービスが連携する際のサービスとしてWorkload Identityというサービスがあります。
以下が公式ドキュメントでの説明の抜粋となります。
ID 連携を使用することで、サービス アカウント キーを使用せずに、Google Cloud リソースへのアクセス権を、オンプレミスまたはマルチクラウドのワークロードに付与できます。
ID 連携は、アマゾン ウェブ サービス（AWS）や、OpenID Connect（OIDC）をサポートする任意の ID プロバイダ（Microsoft Azure など）、SAML 2.0 で使用できます。
従来、Google Cloud の外部で実行されているアプリケーションは、サービス アカウント キーを使用して Google Cloud リソースにアクセスしていました。サービス アカウント キーは非常に強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。
ID 連携を使用すると、Identity and Access Management（IAM）を使用し、外部 ID に対して、サービス アカウントになりすます機能を含む IAM ロールを付与できます。これにより、有効期間の短いアクセス トークンを使用してリソースに直接アクセスでき、サービス アカウント キーに関連するメンテナンスとセキュリティの負担が軽減されます。
GitLab CIが正しい情報を利用することでGCPプロジェクトに有効期間の短いアクセストークンを要求することができます。
というわけで、Workload Identityのプロバイダを設定していきたいと思います。
まずはサイドメニューのIAMの一覧からWorkload Identity連携のページへ行きます。
その中でWorkload Identity プールの中の「プロバイダを追加」を選択します。
そして、以下の画像のようにプールの作成から、そのプールの中にプロバイダを追加します。
2枚目の画像の中で、プロバイダの選択ではOIDCを選択するようにしてください。
そして、発行元（URL）には「https://gitlab.example.com/」、許可するオーディエンスには「https://gitlab.example.com」を設定してください。
最後に「/」があるかないかの違いがあるのでお気を付けください。
次にプロバイダの属性を以下のように設定します。
設定した内容の一覧は以下のようになります。
| OIDC | |
|---|---|
| google.subject | assertion.sub |
| attribute.project_path | assertion.project_path |
| attribute.aud | assertion.aud |
| attribute.project_id | assertion.project_id |
| attribute.ref | assertion.ref |
作成したプロバイダへのアクセス権限を今回作成したサービスアカウントに付与する必要があります。
プロバイダを作成したら遷移する画面内の「アクセスを許可」を押下します。
そして、サービスアカウントにアクセス権を付与します。
この時にフィルタに一致するIDのみを選択し、project_idを選択します。
そして属性値にはGitLabのプロジェクトIDを記載します。
GitLabのプロジェクトIDはGitLabのプロジェクト画面の中にありますので、ご確認ください。
これで、Workload Identity のプロバイダの準備が完了しました。
このプロバイダの情報をGitLab CICDの中のVariablesにて設定する必要があります。
画像の通りに作成している場合は「iam.googleapis.com/projects/[GCPのプロジェクトID]/locations/global/workloadIdentityPools/gitlab-test/providers/gitlab-jwt-test」となります。(GCPのプロジェクトIDのみご自分のプロジェクトIDにご変更ください)
これでGCPプロジェクト側でのWorkload Identityの設定は完了になります。
そして、GitLabのVariablesには以下のように設定されているはずです。
おまけ：GCS
おまけで、その②の中でバックエンドとしてGCSを利用しているので、それ用のバケットをGCSにてあらかじめ作成しておきます。
基本的にはそこまでアクセスするものではないので、Nearlineで作成しました。
ご自身の環境によって変わるところですので、お好きなように設定ください。
最後に
その③ではGCPでの設定内容のお話を記載させていただきました。
手作業やヒューマンエラーを減らし、できるだけ労力をかけず、エンジニアが違うことに時間をさけられるようになれば、この記事の目標は達成できたことになります。
その①から③までの内容によりGCPプロジェクトの自動作成システムが構築できると思います。
ご一読いただきましてありがとうございました。
