G-genの杉村です。
Google Cloud (旧称 GCP) の Identity and Access Management (以下、IAM) の仕組みをきちんと理解しているでしょうか。
IAM は基本機能でありながら、きちんと使いこなせば強力なセキュリティ統制を効かせることができます。
Amazon Web Services (以下、AWS) の IAM とは概念が結構違うところもあり、意外と分かりづらい Google Cloud の IAM 。
本投稿では、その内部構造まで解き明かしていきます。
IAM は使ったことがあるけど、実はよく分かっていないんだよね... という方に向けた内容です。
IAM とは
Google Cloud における Identity and Access Management (IAM) とは Google Cloud リソースに対するアクセス制御を司る仕組みです。
IAM は 誰が、どのリソースに対して、どういう条件で、何をできるか 、という「認可」を管理します。
Google Cloud リソースとは、例えば Compute Engine の VM や BigQuery のテーブルなど、 Google Cloud に存在するオブジェクトの一つ一つを指しています。
また Google Cloud のテナントである「プロジェクト」やそれらを管理する箱である「組織」もリソースの一つです。
これらに対する操作権限を定義する仕組みが IAM です。
ID (Google アカウント等)
IAM を理解するには Google Cloud における ID (アカウント) 管理を理解する必要があります。
Google Cloud (GCP) のコンソールにログインしたり、 CLI ツールを実行するための ID は、 Google Cloud では Google アカウント (または単にアカウント) と呼ばれます。
アカウントは個人の Google アカウントでもいいですし、 Google Workspace (旧 GSuite) や Cloud Identity といった仕組みで管理されます。
AWS では ID が IAM User と呼ばれ、 AWS アカウント (テナント) の中で管理されるのとは対象的に、 Google Cloud を利用するための ID の管理は Google Cloud から分離されているのです。
ですから、既に Google Workspace をお使いであればそのままアカウントを Google Cloud の利用アカウントとして活用できます。
Google Workspace をお使いでない場合は、 Cloud Identity という仕組み (無償版で 50 アカウントまで作成可能) で 組織 を作り、 ID 管理が可能です。
Google Workspace でも Cloud Identity でも、アカウント名は john@example.com のようにメールアドレス形式です。
また admin-grp@example.com のように グループ を作成して、アカウントをグループに所属させることができます。
(グループは Google Workspace においてはメーリングリストとして利用することができます)
1 つのアカウントは複数のグループに所属することが可能です。
個人の Google アカウント (Gmail, Google ドライブ, カレンダー) も Google Cloud 利用のためのアカウントとして利用可能です。
ただし、企業で Google Cloud を利用する場合は個人アカウントではなく Google Workspace か Cloud Identity の利用を強くおすすめ します。
個人向け Google アカウント だと、グループなどの強力な管理機能が利用できないためです。
IAM の仕組み
IAM とリソースの関係
Google Cloud の IAM で最も重要なのは IAM 権限はアカウント (主体) とリソースの間に紐づくものである という点です。
ここが AWS の 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 Policy に対して binding を追加することで、基本的にはメンバーに対して、アクション実行の 許可 を与えることになります。
一方で Deny ポリシー を IAM ポリシーとは別に作成することで 明示的な拒否 を指定することも可能です。
ポリシーの評価順は 明示的な Deny > 明示的な Allow > 暗黙の Deny であり、明示的な Deny が最も強いです。
そのためポリシー設計時は 基本的には「明示的な Allow」を付与する/しないで管理することを基本 とし、どうしても強い権限で拒否したい (フタをしたい) ときだけ明示的な Deny を使う、といった手法が良いでしょう。 Deny ポリシーは強力すぎるため、安易に使うと後から修正が難しくなる場合があるためです。
また注意点として Deny ポリシーの機能は 2022/03 月現在 Preview 公開 ですので Preview 期間が終わり GA (一般公開) されるまでは、本番環境は避けるべきです。当面は Allow する/しない によって権限管理を行うことになります。
Deny ポリシーの詳細については以下の記事で解説しています。
IAM の内部構造 (IAM Policy とは)
内部構造にも少しふれておきます。
全てのリソース (組織、フォルダ、プロジェクト、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 コマンドによる IAM Policy 操作
ここまで分かれば、コマンドラインツール 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 との比較
ID (IAM User)
マネジメントコンソールにログインしたり、 CLI ツールを実行するための ID は、 AWS では IAM User と呼ばれ、 AWS アカウント (テナント) の中で管理されます。
Google Cloud (GCP) の ID は Google Cloud とは分離され Google Workspace や Cloud Identity で管理されることとは対照的です。
概念の違い
AWS IAM では IAM Policy で権限セット (できること) を定義し、それを 権限主体 (IAM User や Group 。総称してプリンシプル) に紐づけ ます。
別の言葉で言うと、 "どのリソースに対して" "何ができるか" という権限セットを 人に紐づける のです。
これは 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 |
杉村 勇馬 (記事一覧) (Facebook)
クラウドソリューション部 部長
元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格10冠。
2022年5月現在、ハマっているものはモンスターエナジーウルトラ。
Follow @y_sugi_it