Google Compute Engine (GCE)において、VMインスタンスから他のサービスのAPIを叩けるようにするには、
サービスアカウントとアクセススコープの両方でアクセス権限を付与する必要があります
片方でしか許可してないと、アクセスは拒否されます
そこで、以下の疑問が浮かびました
- 何故サービスアカウントとアクセススコープの両方で許可をしないといけないのか
- 結局アクセススコープはどのように扱うのがベストプラクティスなのか
調べた結果たどり着いた結論
何故サービスアカウントとアクセススコープの両方で許可をしないといけないのか
アクセススコープはレガシーな方法であり、本当はサービスアカウントで権限管理をしたほうが良い
だけどアクセススコープベースでの権限管理を続けたい人のために、今の形になっている
基本的に「権限管理に使わない方では全部のAPIを許可する」
- アクセススコープで権限管理するなら、サービスアカウントはGCE用のデフォルトのものを使用する（編集者ロールが付与されている）
- サービスアカウントで権限管理するなら、アクセススコープは全てのAPIを許可する
結局アクセススコープはどのように扱うのがベストプラクティスなのか
公式ドキュメントに書いてあるとおり、サービスアカウントベースの権限管理をするのがベストプラクティス
- デフォルトのGCE用サービスアカウントは使わない
- 各VMインスタンス用の自作のサービスアカウントを用意
- アクセススコープは全部のAPIを許可
もう少し詳しく
GCEにおいては、具体的には次の2パターンの方法で権限管理ができます
アクセススコープベースでの権限管理
こちらの場合、サービスアカウントはGCE用にデフォルトで用意されているものを使用します
GCE用にデフォルトで用意されているサービスアカウントは編集者ロールが付いているため、ほぼ全てのAPIが許可されています
そのうえで、アクセススコープを用いて権限管理を行います
コンソール画面はこうなります
サービスアカウントベースでの権限管理
こちらがベストプラクティスとなります
こちらの場合、サービスアカウントはVMインスタンス毎に自作のものを用意します
そのうえで、アクセススコープは全部のAPIを許可するように設定します
これによって、権限管理においてアクセススコープを意識する必要がなくなります
コンソールにおいては、自作のサービスアカウントを設定すると、アクセススコープは設定変更することすらできなくなります
※ 「my-sa-vm」が事前に自作したサービスアカウント
（おまけ）cloud-platform
アクセススコープのベストプラクティスについて、公式ドキュメントは以下のように記載されています
使用可能なアクセス スコープは多数ありますが、ベスト プラクティスは
cloud-platformアクセス スコープを設定することです。これは、ほとんどの Google Cloud の OAuth スコープです。サービス アカウントに IAM ロールを付与し、サービス アカウントのアクセス権を制御できます。
「cloud-platform アクセス スコープ」というワードが出てきますが、
直下のスコープの例に記載されている通り、
「cloud-platform アクセス スコープを設定する」=「全てのAPIを許可する」
です
TerraformでVMインスタンスを作成する際に、このことを意識する必要があります
Terrafromにおいては、自前のサービスアカウントを指定していたとしてもアクセススコープの指定をする必要があります
そこで、以下のようにservice_account.scopesに"cloud-platform"を指定することで、ベストプラクティスに則ることができるのです
resource "google_compute_instance" "my_vm" {
...
service_account {
email = google_service_account.my_vm.email
scopes = [ "cloud-platform" ]
}
...
}