> Google > GitLabとGoogle Cloudを連携するWorkload Identity Federation

GitLabとGoogle Cloudを連携するWorkload Identity Federation

2023.08.29 2023.09.06

GitLabとGoogle Cloudを連携するWorkload Identity Federationについて説明します。

本記事では、Google Cloud と GitLabの連携について紹介したいと思います。

GitLabについて

GitLabは、ソース管理をコア機能として、DevOps/DevSecOps全般に渡って幅広い機能を提供する統合型開発プラットフォームです。
GitLab社が運用するクラウド型SaaS版に加えて、オンプレミスでも稼働させるSelf-Managed版があります。
購入できるエディションは、フリー版に加えて、Premium版、Ultimate版があります。
フリー版の場合、スコープドラベルなど非常に便利な機能が無いなど、注意が必要です。

GitLabについてはこちらもご参照ください。
https://www.synnex.co.jp/vendor/gitlab/

Google Cloud と GitLabの連携について

昨今、DevOpsという言葉が一般化してきており、Google Cloud でシステム構築する上でも、DevOpsを意識することが多くなってきました。これを実現する上でも、Gitリポジトリとの連携が欠かせない物となっています。 Google Cloud と GitLabで連携したいケースは色々あると思いますが、その中の一つとして、Gitで管理されているソースコードをmainブランチなど特定のブランチにマージした際や特定のタグを付けた際に、アプリケーションのデプロイを自動化を検討することがあります。

Google Cloud と外部のサービスと連携する際によく使われる方法として、Google Cloudでサービスアカウントを作成し、アクセスキー（JSONファイル）をダウンロードし、外部サービス側に設定することでGoogle Cloudへのアクセスをできるようにする方法があります。

この方法は、よく使われる方法ではありますが、アクセスキーが外部に流出した際には、どこからでもGoogle Cloudにアクセスできてしまう。というリスクが伴います。そのため、サービスアカウントに付与する権限を必要最低限のものにするなどの被害を最小にするための対応を取る必要があります。

Google CloudとGitLabを連携する方法としては、GitLabのGitLab CIを設定し、特定のブランチにマージした際に起動するようにし、Google Cloud 側の Cloud Source Repositories に連携する。という方法があります。この場合には、GitLab CI側に設定するサービスアカウントの権限をCloud Source Repositoriesへの書き込み権限のみにすることで、最小の権限を付与した形になります。

この形式でも、外部からCloud Source Repositoriesに直接悪意のあるコードが書き込まれる可能性は排除できません。

これらをよりセキュアにする方法として、 Workload Identity Federation を利用する方法があります。

Workload Identity Federationについて

設定方法につきましては、こちらのGitLab社の公式ドキュメントで公開されています。
Configure OpenID Connect with GCP Workload Identity Federation

Google Cloud 側のサービスアカウントの権限を安全にGitLab側のアカウントに貸し出す方法で、一般的に利用されている OpenID Connect (OIDC) を利用して安全に接続する方法です。

Workload Identity Federationを設定することで、アクセスキーをダウンロードすることなく、GitLab側の権限変更や権限の取り消しをGoogle Cloud側で制御することが出来るようになり、よりセキュアにGitLabからGoogle Cloud への接続が出来るようになります。

公式サイトの設定手順

GitLab、Google Cloud の公式サイトは以下となります。

■GitLab
設定方法は上でも紹介した、GitLab社のドキュメントに詳しく記載されています。
Configure OpenID Connect with GCP Workload Identity Federation

■Google Cloud
他の ID プロバイダとの Workload Identity 連携を構成する

※ 少し注意が必要な点ですが、GitLabのドキュメントでは、「AWS または Azure」の設定へのリンクがありますが、GitLabはOIDCを利用した接続になりますので、Google Cloud の公式サイトのドキュメントは、「他の ID プロバイダ」を参照すると良いと思います。

以下に設定方法を簡単に紹介します。

設定手順

ここから以下の手順を説明します。

Workload Identity プールを作成
Workload Identity プロバイダーを作成
属性マッピング設定
サービスアカウントになりすまし権限設定

(1) Google Cloudの設定画面を開く

(1)-1 Google Cloud のメニューから Workload Identity 連携を開く

(1)-2 Workload Identity プールを作成を開く

このメニューでプロバイダの作成まで行えます。

(2) プール作成

以下のように入力して下さい。

名前： Gitlab
説明：目的がわかるように記載して下さい
※ プールIDは、自動で作成されます。編集も可能ですがそのまま利用します。

(3) プロバイダー作成

同じ画面から、引き続きプロバイダーを作成します。以下のように入力して下さい。

プロバイダの選択： OpenID Connect (OIDC)
プロバイダ名： gitlab/gitlab
発行元(URL)： https://gitlab.com/
オーディエンス：許可するオーディエンスにチェックを入れ https://gitlab.com を入力
※ プロバイダIDは、プロバイダ名を入力すると自動で設定されます。今回の設定では、 gitlab-gitlab となります。 ※ 発行元とオーディエンスは、最後の / の有無に注意して下さい。

(4) 属性マッピング設定

属性のマッピング設定します。 google.subject と assertion.sub のマッピングは必須になります。

その他の項目は、任意で設定します。

属性を設定することで、GitLab側で権限を利用できる条件を設定できるようになります。特に、gitlab.com を使用している場合などは、条件を追加しないとgitlab.com 全体に対して許可を与えてしまうので、注意して下さい。

例えば、上記で設定したように、 attribute.project_path と assertion.project_path をマッピングし、条件CELに以下を設定することでGitLab側の特定のプロジェクトに限定して許可を設定することが可能になります。

attribute.project_path == "mygroup/myproject"

※ mygroupは、ご利用のGitLabリポジトリのグループ。myprojectは、ご利用のGitLabリポジトリのプロジェクトを指定して下さい。

assertion.user_email を利用すると、GitLab CIを実行したユーザーに限定することも可能になります。

GitLab側で利用できる項目はこちらに一覧記載があります。
OpenID Connect (OIDC) Authentication Using ID Tokens – Token payload

(5) サービスアカウントになりすまし権限設定

GitLab側のアカウントがGoogle Cloudのサービスアカウントになりすますための設定を行います。

対象の権限を設定したサービスアカウントを用意し、作成したWorkload Identityプールに接続する設定を行います。

Google Cloud側で権限を設定するサービスアカウントを作成

Workload Identity Federation は、Google Cloud側のサービスアカウントの権限を借用する形で動作します。
連携専用のサービスアカウントを作成して利用します。

ここでは、作成したサービスアカウントに以下の権限を付与して、Cloud Soruce Repositoryへの書き込み権限のみを付与しています。

作成したサービスアカウントをWorkload Identityプールと接続します。

作成したサービスアカウントが選択できるようになっているので、こちらで選択します。

これで、GitLab側のアカウントとGoogle Cloudのサービスアカウントを接続することができるようになります。

実際に利用する際には、接続要件によって、追加の条件設定等が必要になります。利用する際には、注意して利用して下さい。

利用方法

GitLab社にてサンプルプロジェクトが公開されています。 Configure OpenID Connect In Google Cloud

こちらのリポジトリで、 .gitlab-ci.yml にて Workload Identity Federation を使用した認証方法が記載されています。

こちらのリポジトリでは、terraform での設定なども入っておりとても参考になります。

Cloud Source Repositoriesへpushするgitlab ciの設定サンプル

GitLab社のサンプルをカスタマイズして、mainブランチにpushまたは、マージされた際にCloud Source Repositoriesにpushするサンプルは以下のようになります。

.gitlab-ci.yml を作成し、以下のように記載をして下さい。

gcp-gitpush:
  image: google/cloud-sdk:slim
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  script:
    - export
    - echo ${CI_JOB_JWT_V2} > .ci_job_jwt_file
    - gcloud iam workload-identity-pools create-cred-config ${GCP_WORKLOAD_IDENTITY_PROVIDER}
      --service-account="${GCP_SERVICE_ACCOUNT}"
      --output-file=.gcp_temp_cred.json
      --credential-source-file=.ci_job_jwt_file
    - gcloud auth login --cred-file=`pwd`/.gcp_temp_cred.json
    - gcloud auth list
    - git config --global credential.'https://source.developers.google.com'.helper gcloud.sh
    - set +e
    - git branch -d ${CI_COMMIT_REF_NAME}
    - git checkout -b ${CI_COMMIT_REF_NAME}
    - git remote rm google
    - set -e
    - git remote add google https://source.developers.google.com/p/fg-gcp-trial/r/gcp-trial
    - git push -f google ${CI_COMMIT_REF_NAME}

${GCP_WORKLOAD_IDENTITY_PROVIDER} の部分は以下のような形式になります。

projects/000000000000/locations/global/workloadIdentityPools/gitlab/providers/gitlab-gitlab
※ 000000000000は、ご利用のプロジェクトIDに置き換えてください。

${GCP_SERVICE_ACCOUNT}の部分は、設定したサービスアカウントをメールアドレス形式で置き換えてください。

「CI」で始まっている環境変数は、GItlab側で設定されている環境変数を利用しています。

まとめ

GitLabなど外部のサービスやオンプレサーバーなどからGoogle Cloudへのアクセスにはアクセスキーを利用することが多かったかと思います。

アクセスキーの利用は流出した際の危険性を考慮する必要がありました。

Workload Identity Federationを利用することで、Google Cloud側で権限を制御しながら柔軟に利用することが出来ます。ぜひ導入をご検討ください。

Google Cloudの導入は当社にご相談ください

ITディストリビューターであるTD SYNNEXはGoogle Cloud™ Partner Award を受賞するなど、長年にわたりGoogle™のグローバル認定ディストリビューターとして、総合的な Googleソリューションを提供しています。お客様にとって最適なソリューションの提案や導入、活用をサポートします。

製品・サービスについてのお問合せ

情報収集中の方へ

導入事例やソリューションをまとめた資料をご提供しております。

資料ダウンロード

導入をご検討中の方へ

折り返し詳細のご案内を差し上げます。お問い合わせお待ちしております。

お問い合わせ

目次