GCPのリソースと認証・認可の方法

GCP上のリソースにアクセスする場合、公式から提供されているCLIやプログラムからアクセスするためのSDKなど、使用するクライアントに応じて複数の認証・認可の方法が用意されている。どのような場合にどの認証・認可方法を採用すべきか迷うことが多いので、整理しておきたい。

まず、認証と認可について簡単に整理しておく。Auth0のドキュメントより

認証・認可の種類

操作によって認証・認可の方法が異なる

認可の方法

特定のGoogleユーザーとは関係のないサービスアカウントを使用した認可方法
Cloud SDK を本番環境へのマシンのデプロイの一環としてインストールして設定する場合や、すべてのユーザーが root にアクセスできる Compute Engine 仮想マシンインスタンスで使用する場合に推奨される。
- CIやCDなど
- 運用効率化のためのシステムから各コマンド実行したい場合は、特定のユーザーに紐づいていない形で実行したいはずなのでこっち？

認可の方法

Application Default Credentials (ADC)を使うことが推奨される
ADCに則ることで、Google Client LibraryやGoogle API Client LibraryなどのSDKを使用したアプリケーションプログラムから認可済の認証情報を自動で検索して使用することがきる
ADCを使用すると、同じ認証・認可方法で開発環境や本番環境でコードを実行することができるので管理もしやすい

GOOGLE_APPLICATION_CREDENTIALS環境変数
- Workload Identity 連携の認証情報構成ファイル
  - Workload Identity 連携の認証情報構成ファイル
  - こちらで分かりやすく解説されている
- サービスアカウントキー
  - 漏洩するリスクが高いため、非推奨
gcloud cliで設定されたユーザー認証情報
- gcloud auth application-default login
- 提供された認証情報（通常は Google アカウントからの認証情報）を含むJSON ファイルがファイルシステム上に配置される
  - LinuxやMacだと$HOME/.config/gcloud/application_default_credentials.json
  - 操作対象のアカウントが持つ複数のプロジェクトの認証情報がJSONファイルに書き込まれる(1アカウントで複数のプロジェクトのリソースに認証を通すことができる)
接続済のサービスアカウント
- VMをはじめとしたGoogle Cloudのリソースに紐付けられたサービスアカウント
- コンピューティングリソースに設定されたサービスアカウントに権限をもたせれば、わざわざアプリケーションにサービスアカウントを設定する必要はない

上から順番に検索に該当したものが選択・使用される

リモート環境での認証・認可方法の使い分けに関しては、公式ドキュメントに判断のためのフローチャートが用意されていた。

ローカル環境でクライアント毎にどの認証・認可の方法を採用するとよさそうか、同じようにフローチャートで整理しておく。