G-genの杉村です。 Google Cloud(旧称 GCP)の Identity and Access Management(IAM)における拒否ポリシー(Deny policies)について解説します。
はじめに
IAM とは
Google Cloud(旧称 GCP)の Identity and Access Management(以下、IAM)は Google Cloud リソースの操作権限を管理する仕組みです。IAM は、認証された Google アカウント等に対して、どんな権限を与えるか(認可)を司ります。
IAM の基本的な解説については以下の記事をご参照ください。
拒否ポリシーとは
拒否ポリシー(Deny policies)とは、リソースへの操作を明示的に拒否する IAM 設定のことです。
Google Cloud の IAM では、何も設定しないデフォルト状態だと、すべての操作が拒否されます。各リソースが持っている IAM ポリシーにおいてプリンシパル(Google アカウントやグループ等)を IAM ロールと紐づけると、操作が許可されます(明示的な Allow)。
拒否ポリシーは、最も強い優先度を持ちます。IAM ポリシーで明示的な Allow が与えられても、拒否ポリシーが最も優先され、操作は拒否されます。
- 参考 : 拒否ポリシー
IAM ポリシーの評価順
IAM のポリシーが評価される際、以下のような順番で評価されます。
明示的な Deny > 明示的な Allow > 暗黙の Deny
IAM では、権限がリソース階層の親から子へ(上から下へ)継承されます。階層のどこかで Deny ルールが存在すると、これが最も優先されることになります。図示すると、以下のようになります。
仕組み
拒否ポリシーの性質
拒否ポリシーは、通常の IAM ポリシーとは独立したオブジェクトです。
そのため gcloud projects get-iam-policy
などでリソースの IAM ポリシーを閲覧しても、拒否ポリシーは表示されません。
例として、あるプロジェクトの通常の IAM ポリシーを取得するための gcloud コマンドを示します。
gcloud projects get-iam-policy your-project-name
上記のコマンドを実行すると、明示的な許可を示す IAM bindings が表示されるのみで、拒否ポリシーは表示されません。
拒否ポリシーを表示するには、以下のようなコマンドを実行します。
gcloud iam policies get my-deny-policy \ --attachment-point=cloudresourcemanager.googleapis.com/projects/your-project-name \ --kind=denypolicies
また、以下のようなコマンドを実行します。
gcloud projects get-ancestors-iam-policy sugimura --include-deny
拒否ポリシーの作成は、以下のようなコマンドを実行します。
gcloud iam policies create my-deny-policy \ --attachment-point=cloudresourcemanager.googleapis.com/projects/your-project-name \ --kind=denypolicies --policy-file=policy.json
これらから、拒否ポリシーは通常の IAM ポリシーとは異なるオブジェクトであることが分かります。
拒否ポリシーを管理するための IAM 権限
拒否ポリシーの閲覧・作成・編集・削除には、Deny Admin(roles/iam.denyAdmin)
などのロールが必要です。
たとえプロジェクトレベルでオーナー(roles/owner)ロールを持っていても、拒否ポリシーの作成・編集・削除はできず、閲覧ができるのみです。
- 参考 : Required roles
拒否ポリシーの管理
拒否ポリシーは、Web コンソール、gcloud コマンドライン、REST API 経由で管理できます。
拒否ポリシーに関する各種手順については、以下のドキュメントを参照してください。
- 参考 : リソースへのアクセスを拒否する
拒否ポリシーの構成要素
拒否ポリシーは、以下のような要素で構成されています。
- 拒否対象のプリンシパル
- 除外するプリンシパル(オプション)
- 拒否するパーミッション
- 拒否する条件(オプション)
はじめに、1.
の「拒否対象のプリンシパル」とは、操作を拒否する対象のプリンシパルを指定します。プリンシパルとは、Google アカウントや Google グループ、サービスアカウント等、Google Cloud API を実行する主体を指します。ここでは、複数のプリンシパルを指定することができます。
2.
の「除外するプリンシパル」は、1.
で指定したプリンシパルのうち、対象外とするプリンシパルを指します。例えば 1.
で拒否対象のプリンシパルとして hogehoge@example.com
という Google グループを指定したとします。2.
にて john@example.com
というプリンシパルを除外対象として指定すれば、john
が hogehoge
グループに所属していても、拒否対象にはなりません。
3.
の「拒否するパーミッション」は例として cloudresourcemanager.googleapis.com/projects.delete
などの、パーミッションを指定します。通常の IAM ポリシーでは権限の指定方法として IAM Role を指定するのに対して、拒否ポリシーでは パーミッションを指定 することに注意が必要です。
4.
の「拒否する条件」は、アクションを拒否する条件を指定します。この条件に一致したときだけ、アクションが拒否されます。例えば、特定のリソースタグを付与したリソースに対する操作だけを拒否できます。
継承
通常の IAM ポリシーと同様に、拒否ポリシーも上位リソースから下位リソースに継承されます。
組織レベルで付与したポリシーは下位のフォルダーやプロジェクトに継承されます。また、フォルダーレベルで付与したポリシーは下位のプロジェクトに継承されます。プロジェクトに付与したポリシーは、プロジェクト内の全てのリソースに継承されます。
拒否ポリシーは最も優先されるため、上位リソースの IAM ポリシーで明示的に許可された権限を、下位リソースに追加した拒否ポリシーで拒否する、といったことが可能です。
IAM ポリシーの例
以下は、公式ドキュメントから引用した拒否ポリシーです。
{ "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion", "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816", "kind": "DenyPolicy", "displayName": "Only project admins can delete projects.", "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=", "createTime": "2021-09-07T23:15:35.258319Z", "updateTime": "2021-09-07T23:15:35.258319Z", "rules": [ { "denyRule": { "deniedPrincipals": [ "principalSet://goog/public:all" ], "exceptionPrincipals": [ "principalSet://goog/group/project-admins@example.com" ], "deniedPermissions": [ "cloudresourcemanager.googleapis.com/projects.delete" ], "denialCondition": { "title": "Only for non-test projects", "expression": "!resource.matchTag('12345678/env', 'test')" } } } ] }
この Deny ルールでは deniedPrincipals
にて、すべての Google ユーザーが対象となっています。
しかし exceptionPrincipals
にて project-admins@example.com
が指定されているため、このグループだけはこの拒否ポリシーの対象外です。とはいえ、明示的な拒否の対象外となるだけですので、このグループがリソースに対して操作を行うには、IAM ポリシーで明示的な許可が必要です。
deniedPermissions
にて、この拒否ルールの対象が cloudresourcemanager.googleapis.com/projects.delete
、すなわちプロジェクトを削除する権限であることが分かります。
denialCondition
にて、env
: test
というリソースタグがついているプロジェクトに限られていることが分かります。
拒否ポリシー利用の注意点
使い所
ポリシーの評価順は 明示的な Deny > 明示的な Allow > 暗黙の Deny であり、明示的な Deny が最も強いです。
そのため IAM 権限体系の設計時は、まず拒否ポリシーを使わずに、通常の IAM ポリシー(明示的な Allow)を付与するかしないか、で管理することを原則とし、どうしても強い権限で拒否したい(権限にフタをしたい)ときだけ明示的な Deny を使う、という方針にすることが望ましいです。拒否ポリシー(明示的な Deny)は強力すぎるため、安易に使うと後から修正が難しくなる場合があるためです。
拒否できるアクション
拒否ポリシーでは、すべてのアクションが拒否対象にできるわけではありません。拒否できるアクションの一覧が公開されており、サポート対象の権限(アクション)以外は、拒否できません。
最新の対象権限(アクション)は、以下のドキュメントをご参照ください。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it