これで分かった！Google CloudのIAMの仕組みやAWSとの違い

G-genの杉村です。

Google Cloud の Identity and Access Management (以下、IAM) の仕組みをきちんと理解しているでしょうか。
IAM は基本機能でありながら、きちんと使いこなせば強力なセキュリティ統制を効かせることができます。

Amazon Web Services (以下、AWS) の IAM とは概念が結構違うところもあり、意外と分かりづらい Google Cloud の IAM 。
本投稿では、その内部構造まで解き明かしていきます。

IAM は使ったことがあるけど、実はよく分かっていないんだよね... という方に向けた内容です。

IAM

詳述！ IAM の仕組み

IAM とリソースの関係

Google Cloud の IAM で最も重要なのは IAM権限はリソースに紐づくものである という点です。
ここが AWS の IAM と最も違うところでもあります (後述) 。

リソースとIAMの関係

リソースに対して「誰が (Googleアカウント/グループ等。総称してメンバーと呼ばれる) 」「何を (IAM ロール) 」できるかを紐づけているのです。
リソースとは Compute Engine の個々のインスタンスであったり、 BigQuery のデータセットなどを指します。
なおプロジェクト自体もリソースですし、組織もリソースです。

継承

上位のリソースに権限を紐づけると、下位のリソースに 継承 されます。
例えば組織に対して 「XXX@example.com」「IAM Role: オーナー」 という権限を紐づけると XXX@example.com さんは組織配下にある全てのリソース (フォルダ、プロジェクト、VM インスタンスや BigQuery データセット) にオーナー権限をふるうことができます。

プロジェクトに対して 「XXX@example.com」「IAM Role: オーナー」 という権限を紐づけると XXX@example.com さんはプロジェクト配下にある全てのリソース (VM インスタンスや BigQuery データセット) にオーナー権限をふるうことができます。

継承

反対に、一つの VM インスタンスにオーナー権限を付与しても、XXX@example.com さんは その VM にだけオーナー権限を行使できる のであって他のリソースに触れたり閲覧することはできません。
これを理解できれば 何にどんな権限付与すると、どこまで効果が及ぶのか を理解できるでしょう。

IAM の内部構造

内部構造にも少しふれておきます。

内部構造

全てのリソース (組織、フォルダ、プロジェクト、VM インスタンスや BigQuery データセット) は IAM Policy という属性を一つだけ持っています。
※ AWS でいう IAM Policy とは全く別物のため、注意です。
IAM Policy は 一つのリソースにつき、一つだけ です。

IAM Policy は複数の binding を持つことができます。
binding の中には "誰が (Googleアカウント/グループ等。総称してメンバーと呼ばれる) " "何を (IAM ロール)" "どういう条件で (condition)" できるのか、という情報が入っています。

あるリソースの IAM Policy を JSON として describe すると以下のようになります。

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:divya@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "********",
  "version": 1
}

御覧のように、一つの IAM Policy の中に配列で複数の bindings が入っており、一つの binding の中にはどういう条件 (condition) で誰が (メンバー) 何をできる (IAM ロール) のかが記述されている、ということが分かります。

gcloud コマンドの記述の仕方

ここまで分かれば、コマンドラインツール gcloud で IAM 権限を付与するときは、以下のようにする理由が分かるでしょう。

プロジェクト全体に IAM 権限を付与するとき

gcloud projects add-iam-policy-binding my-project-id --member='user:test-user@gmail.com' --role=roles/resourcemanager.projectCreator `

VM インスタンスに IAM 権限を付与するとき

gcloud compute instances add-iam-policy-binding my-instance --zone=asia-northeast1-b --member='user:test-user@gmail.com' --role='roles/compute.securityAdmin'

各リソースの IAM Policy に対して "add-iam-policy-binding" をすることで、 binding を追加しているのです。

AWS IAM との比較

概念の違い

AWS IAM では IAM Policy で権限セット (できること) を定義し、それを 権限主体 (IAM User や Group 。総称してプリンシプル) に紐づけ ます。

別の言葉で言うと、 "どのリソースに対して" "何ができるか" という権限セットを 人に紐づける のです。

これは Google Cloud の IAM が "誰が" "何をできるか" を "リソースに紐づける" のとは考えが異なりますね。

AWS IAM と Google Cloud IAM の比較

用語の違い

IAM Policy, IAM Role といった言葉は 両クラウドで共通していますが、意味は大きく異なっています。 混同しないように気を付けましょう。

意味	AWSでの用語	Google Cloud の用語
権限セット	IAM Policy	IAM Role
権限を実行するIAM主体 (人間)	IAM User	Google アカウント
権限を実行するIAM主体 (サービス)	IAM Role	サービスアカウント
人のIAM主体をまとめるグループ	IAM Group	Google グループ
個々のリソースが持つIAM設定	(対応概念なし)	IAM Policy

杉村 勇馬 (記事一覧)

クラウドソリューション部 部長

クラウド管理運用やネットワークに知見あり。AWSの全資格をコンプリートしたので、次はGoogle Cloudの認定資格を狙っている。

2021年10月現在、ハマっているものはマーベル (遅い)