Google Cloudの認証周りを整理:サービスアカウントとADCの基本
はじめに
専らAWSを触ることが多かったのですが、最近になってGoogle Cloudを触る機会が増えてきたので認証周りについて少しまとめようと思います。
Google Cloudに限らずアプリケーションの認証は、セキュリティやアクセス制御の観点から非常に重要です。適切に設計・運用するためには、IAM(Identity and Access Management)、サービスアカウント、アプリケーション デフォルト認証情報 (ADC) など、主要な要素をある程度理解しておく必要があると思いましたので、学んだことを整理します。
言葉の整理
IAM
Cloud IAMは、Google Cloud内で「誰が」「何に対して」「どんな操作ができるのか」を管理するための仕組みです。
例えば、
「開発者Aさんが」「Cloud Storageに対して」「閲覧と編集ができる」であったり
「Cloud Functionsが」「Cloud Storageに対して」「作成のみを行える」
などがあります。
サービスアカウント
- Google Cloudのアプリケーションやサービスが他のGoogle Cloudリソースにアクセスするためのアカウントです。雑に言うと、人間以外のためのシステム用のアカウントです。
- 実際の人間ではないけど、ある権限を持つ「人(ユーザ)」のように扱えたりします。 - 「Cloud Functionsが」が「Cloud Storage」にアクセスするために、それが可能なIAMロールをサービスアカウントに割り当てる と言った使い方をしたりします。
AWSと比較
よく混乱しやすい用語の整理(ざっくり)
GC | AWS | 一言で言うと |
---|---|---|
Googleアカウント | IAM User | 認証に使うユーザ情報 |
サービスアカウント | IAM Role | システムのためのアカウント |
サービスアカウントの権限管理
サービスアカウントはCloud IAMを通じて管理され、IAMロールを割り当てることで、どのリソースにどの権限でアクセスできるかを制御します。
例えば、Cloud Storageのデータにアクセスするための「Storage Object Viewerロール」を特定のサービスアカウントに付与することで、そのアカウントはデータの閲覧が可能になります。
アプリケーション デフォルト認証情報 (ADC)
アプリケーションのデフォルト認証情報 (Application Default Credentials: ADC) は、Google CloudアプリケーションがGoogle Cloudサービスにアクセスする際に使用される認証情報の自動取得機構です。
ADCの動作
ADCの自動検出には、実行順序があります。
- 環境変数 「GOOGLE_APPLICATION_CREDENTIALS」 で指定されたサービスアカウントキー(があるjsonファイルのパス)。
- gcloudコマンド で設定されたユーザーの資格情報。
- Google Cloud環境(Compute EngineやCloud Functionsなど)で提供されるデフォルトのサービスアカウント。 前述のリソースなどでは、インスタンス作成時やデプロイ時にアタッチするサービスアカウントを指定できます!(何も指定していなければデフォルトのサービスアカウントがアタッチされます)
サービスアカウントキーの扱いはちょっと怖い
こちらでもあるように、サービスアカウントキーを直接使う方法(環境変数にGOOGLE_APPLICATION_CREDENTIALSを設定してJSONキーを使う方法)は避けるのが推奨されています
ただし、ローカル開発や特定のテスト環境では、サービスアカウントキーを使わざるを得ない場面もあるため、その場合はキーの管理に注意し、Gitなどに誤ってアップロードされないよう、セキュリティ対策を徹底する必要があります。
ローカル開発であっても、間違えてGithubにあげてしまうと大変危険です。
そしてjsonファイルの管理です。誰が持っているのか(jsonファイルを個別で渡したりする可能性もあります...)、有効期限を適切に設定する...
そこそこ大変そうなので、やはり使わないで実現する方法を選択するのが良さそうです!
サービスアカウントキーを使わないでやってみる
ケース:Cloud RunからCloud Storageに対してデータを保存したい
①ローカルからCloud Storageへアクセスする
Cloud Runにデプロイする前段階ではローカルで開発をしているはずです。この時にCloud Storageへアクセスするための方法として、サービスアカウントキーのjsonファイルを発行して、開発環境に設置して、envでそのパスを指定する...
GOOGLE_APPLICATION_CREDENTIALS=jsonファイルのパス
....でも良いですが、gcloud CLIを使用して認証情報を取得が良いと思います。
gcloud auth application-default login
このにより、ユーザーの資格情報がローカルに保存され、GOOGLE_APPLICATION_CREDENTIALS 環境変数を設定することなく、自動的に認証が行われます。
この方法では、手動でサービスアカウントキーを生成したり管理する必要がありません!
②Cloud RunからCloud Storageへアクセスする
方針としては、サービスアカウントをCloud Runにアタッチし、そのサービスアカウントにCloud Storageへの必要な権限をIAMロールを通じて付与するというものです。
サービスアカウントはCloud Runデプロイ時に作成されるものでも、独自に作成しても良いです。
肝になるのが、「サービスアカウントを他のリソースで使いまわししないこと」「IAMロールで付与する権限は必要最小限であること」だと思います!
また、公式なクライアントライブラリを使用すると、ADCを自動的に検出して、適切なサービスアカウントを利用して認証を行ってくれます。つまり、開発者は追加の認証設定を行う必要がなく、サービスアカウントを通じてGoogle Cloud APIへのアクセスが簡単に管理されます。
※逆に言うと、サポートされていない言語の場合はこの方法では出来ず、下記のようにメタデータサーバにrequestを送る必要がありそうです。
まとめ
認証周りを整理しつつ、ADCの仕組みについてもまとめてみました。
まだGoogle Cloudに関して初心者なので、もし誤解や間違いがあればぜひご指摘くださいmm
他にも、「逆にこうやると良いよ!」といったアドバイスなどあれば是非教えてください。
Discussion