https://cloud.google.com/iam/docs/overview?hl=ja
GCP IAMにはよりきめ細かいRoleがあります。
各GCPサービスには、独自の定義済みのRoleがあり、Roleを適用できる対象が定義されています。
たとえば、Compute Engineでは、仮想マシンをサービスとして提供しており、複数の定義済みRoleが用意されています。
それらは特定のプロジェクト、特定のフォルダ、組織全体のCompute Engineリソースに適用できます。
Compute EngineのInstanceAdmin役割を持つユーザーは、VMに対して特定の操作を行うことができます。
たとえばVMの一覧表示、構成の読み取りと変更、VMの起動と停止です。
多くの会社では最小権限のモデルを使って、各メンバーに必要最小限の権限のみを付与していると思います。
たとえばInstanceOperator-Roleを定義して、特定のユーザーにCompute EngineとVMの起動と停止を許可し、再構成は許可しないとします。
Custom Roleを使えばこれを実現できます。ただし注意点があります。
第一に、Custom Roleを使うことについて、明確に決める必要があります。権限の管理が必要になるからです。
第二に、Custom Roleを使用できるのは、プロジェクトまたは組織レベルのみです。フォルダレベルでは使用できません。
権限を付与する対象がユーザーではなく、Compute Engine VMだとしたら？その場合はサービスアカウントを使用します。
たとえばVMで実行しているアプリのデータを、Google Cloud Storageに保管するとします。
そのデータへのアクセスは、インターネット上の全員に許可するのではなく、VMだけに許可します。
そこで、Cloud Storageに対してVMを認証するためのサービスアカウントを作成します。
サービスアカウントの名前はメールアドレスにします。ただし、パスワードではなく、暗号鍵でリソースにアクセスします。
サービスアカウントにCompute EngineのInstanceAdmin役割が付与されているとします。
VMで実行中のアプリはこのアカウントを使って、他のVMを作成、変更、削除できます。
サービスアカウントの管理について。
たとえば Aが特定のサービスアカウントで、実行可能な操作を管理するとします。
一方、Bは表示さえできれば十分であるとします。サービスアカウントはIDであると同時に、リソースでもあるため、IAMポリシーをそれ自体に適用できます。
サービスアカウントでAには編集者の役割を、Bには閲覧者の役割を付与できます。
さらに複雑な例を紹介します
Compute Engineの複数のVMにまたがって、実装されたアプリがあるとします。
あるアプリコンポーネントには、別のプロジェクトでの編集者役割が必要ですが、他のコンポーネントには不要です。
そこで２つのサービスアカウントを作成します。VMのサブグループごとに１つ作成します。
この場合、最初のサービスアカウントにだけ、別のプロジェクトでの権限を与えます。
これで、アプリのコードが誤っていたり、VMが感染したりしたとしても、その影響を軽減できます。