株式会社G-gen の技術ブログ

全849件

2022/03/09

G-genの杉村です。Google Cloud（旧称 GCP）の Identity and Access Management （IAM）における拒否ポリシー（Deny policies）について解説します。はじめに IAM とは拒否ポリシーとは IAM ポリシーの評価順仕組み拒否ポリシーの性質拒否ポリシーを管理するための IAM 権限拒否ポリシーの管理拒否ポリシーの構成要素継承 IAM ポリシーの例拒否ポリシー利用の注意点使い所拒否できるアクションはじめに IAM とは Google Cloud（旧称 GCP）の Identity and Access Management （以下、IAM）は Google Cloud リソースの操作権限を管理する仕組みです。IAM は、認証された Google アカウント等に対して、どんな権限を与えるか（認可）を司ります。 IAM の基本的な解説については以下の記事をご参照ください。 blog.g-gen.co.jp 拒否ポリシーとは拒否ポリシー（Deny policies）とは、リソースへの操作を明示的に拒否する IAM 設定のことです。 Google Cloud の IAM では、何も設定しないデフォルト状態だと、すべての操作が拒否されます。各リソースが持っている IAM ポリシーにおいてプリンシパル（Google アカウントやグループ等）を IAM ロールと紐づけると、操作が許可されます（明示的な Allow）。拒否ポリシーは、最も強い優先度を持ちます。IAM ポリシーで明示的な Allow が与えられても、拒否ポリシーが最も優先され、操作は拒否されます。参考 : 拒否ポリシー IAM ポリシーの評価順 IAM のポリシーが評価される際、以下のような順番で評価されます。明示的な Deny > 明示的な Allow > 暗黙の Deny IAM では、権限がリソース階層の親から子へ（上から下へ）継承されます。階層のどこかで Deny ルールが存在すると、これが最も優先されることになります。図示すると、以下のようになります。 IAM Policy 評価フロー仕組み拒否ポリシーの性質拒否ポリシーは、通常の 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 ポリシーの例以下は、公式ドキュメントから引用した拒否ポリシーです。参考 : Structure of a deny policy { "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）は強力すぎるため、安易に使うと後から修正が難しくなる場合があるためです。拒否できるアクション拒否ポリシーでは、すべてのアクションが拒否対象にできるわけではありません。拒否できるアクションの一覧が公開されており、サポート対象の権限（アクション）以外は、拒否できません。最新の対象権限（アクション）は、以下のドキュメントをご参照ください。参考 : Permissions supported in deny policies 杉村勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部部長元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

株式会社G-gen の技術ブログ

コンテンツ