何気なく使っているWorkload Identity連携をちゃんと調べてみる
GitHub Actions から Google Cloud にデプロイするときには Workload Identity 連携を使いましょう。
という記事を読んでから使うようにしています。
ただ、記事を読んでその通りに設定したら動いただけでそれが何なのかちゃんと調べたことがないので自分なりにまとめてみました。
Workload Identity 連携ってなんだ？
以下が Google Cloud のドキュメントです。
これによると
Workload Identity 連携を使用すると、サービス アカウント キーの代わりにフェデレーション ID を使用して、オンプレミスまたはマルチクラウドのワークロードに Google Cloud リソースへのアクセス権を付与できます。
とのことです。
要するに、サービスアカウントキーを使わなくても Google Cloud へアクセスできるということですね。
じゃあなぜ、Workload Identity を使う必要があるのかということです。
これもわかりやすく記載があり、
Google Cloud の外部で実行されているアプリケーションは、サービス アカウント キーを使用して Google Cloud リソースにアクセスできます。ただし、サービス アカウント キーは強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。Workload Identity 連携により、サービス アカウント キーに関連するメンテナンスとセキュリティの負担が軽減されます。
説明にもありましたが、サービスアカウントキーは非常に協力にも関わらず、誤って Push してしまったりどこかに流出してしまうようなことがあれば簡単に Google Cloud の操作を悪意を持った第三者に行われてしまうということですね。
Workload Identity 連携の基礎知識
Workload Identity プール
外部 ID を管理しているもの。
プロダクション、ステージング、開発とそれぞれ絵の環境や、GitHub、GitLab のような環境ごとにプールを作ることが推奨されている。
基本的に個人で開発するなら Google Cloud のプロジェクトも 1 つで GitHub Actions のみからデプロイすることになるので作るのは STG 環境用と PRO 環境用で 2 つ作ることになりそう。
Workload Identity プールプロバイダ
Google Cloud と IdP（GitHub とか GitLab とか）との関係を記述するもの。
どの IdP を信頼するかの情報であったり、GitHub から送信されてきた情報を検証して通す通さないを決めることができる。
GitHub から送信されてきたリポジトリ名を検証することで、特定のリポジトリのみ許可するといったようなことができる。
実際の例
Workload Identity プールプロバイダで GitHub との関係を設定する
発行元として記述している部分がどのプロバイダかを指定している。
この属性のマッピングでデータの検証に必要な情報の受け渡しなどを行う。
attribute.repository と assertion.repository をマッピングさせることで、GitHub 側から渡されてきたリポジトリ名を後に指定する条件に含めることができる。
今回は attribute.repository の値が特定のリポジトリ名と一致している場合のみ許可するようにしている。
これにより、意図しないリポジトリからアクセスされるのを防いでいる。
サービスアカウントの権限
あとは使用するサービスアカウントに適切な権限を与えてあげる。
今回はビルドした Docker イメージを Artifact Registry に Push してその後 Cloud Run にデプロイする Actions なのでこれらの権限を付けてあげる。
まとめ
普段よく考えずに使用していましたが、改めてよく調べてみるとどういうことをやっているのか、なぜこれができるのかについて少しでも理解できていいですね。
Discussion