AWSとGCPのIAMの違い（主体とIAMオブジェクト編）
直近でGCPを触る機会があり、今まで使用していたAWSとの違いに少し面食らったので備忘録です。
今回はIAMです。
ユーザについて
AWSでは1つのAWSアカウントが管理単位となり、その中でIAMによってアクセス制御を行う。
IAMの主体としてはIAMユーザやIAMロールが存在し、これらに対してポリシーを付与することで各AWSリソースへのアクセスを制御する。
AWSアカウント
\rootユーザ
\IAMユーザ・グループ（人間）
\IAMロール（ユーザ・AWSリソース・外部IDなどが一時的に引き受ける権限）
一方、GCPは明確な階層構造を持つ（AWSでもOrganizationsを使うことで近い構造を実現可能）。
GCPではGoogleアカウント（Cloud Identity / Workspace）を基盤としつつ、「サービスアカウント」や「グループ」などが主体（プリンシパル）となり、これらに対してロールを付与することでアクセス制御を行う。
また、リソースは以下の階層で管理され、上位で付与した権限は下位に継承される。
組織（Organization）
\フォルダ（Folder）
\プロジェクト（Project）
\リソース
プリンシパル（主体）
・Googleアカウント（人間ユーザ）
・サービスアカウント（アプリケーション）
・Googleグループ
↑ 権限があれば対象スコープ配下のリソースを操作可能。
IAMリソースの違い
AWSとGCPでは、IAMで扱う「リソース（オブジェクト）」の考え方にも違いがある。
AWS
主なIAMリソースは以下。
- IAMグループ：IAMユーザの集まり
- IAMユーザ：AWSアカウント内で作成するユーザ（人・アプリ）
- IAMロール：一時的に引き受ける権限（ユーザやサービスがAssumeする）
- IAMポリシー：JSONで権限を定義する
特徴：
- ユーザ・ロール・グループにポリシーをアタッチ可能
- 「誰に何を許可するか」をポリシーで直接制御
- Allow / Denyで細かく制御できる ※GCPでもDenyポリシーは存在するが、通常のIAM設計ではAllowベースで設計するケースが多い
- IAMはID管理と権限管理の両方を担える（ただし実務ではIAM Identity Center等と併用することが多い）
GCP
GCPは主体と権限を分離した設計になっている。
主なIAMリソースは以下。
- Googleアカウント：人間ユーザ
- サービスアカウント：アプリケーション用のアカウント
- IAMロール：権限をまとめたもの
- IAMポリシー：プリンシパルとロールの対応関係（バインディング）を定義
特徴：
- IAMポリシーはリソースに紐づく
- 「誰（プリンシパル）に、どのロールを付与するか」を定義する仕組み
- 権限はロール単位で付与される（個別Permissionの直接付与は不可。ただしカスタムロールで細かい制御は可能）
- 組織階層に基づき権限が継承される
所感
単一のアイデンティティで複数プロジェクトに横断的にアクセス可能であるため、思わず別PJに行けてしまうケースがあったので注意したい。
同名で違う働きをするものがあるので頭がバグる。