Google CloudのIAMにおけるDenyポリシーを解説

G-genの杉村です。 Google Cloud (旧称 GCP) の Identity and Access Management (IAM) における 明示的な Deny ポリシー についての解説記事です。

IAM の Deny policy が 2022/03/03 に Preview 公開、2022/10/25 に GA されました。この発表までは IAM Policy には Allow しか書くことができませんでしたが、当機能で改善されます。

当記事では、この Deny policy について解説していきます。

Deny ポリシーは通常の IAM ポリシー (Allow するポリシー) とは別オブジェクトであり、正しく理解することが必要です。

Identity and Access Management (IAM)

IAM とは

Google Cloud (旧称 GCP) の Identity and Access Management (以下、IAM) は Google Cloud リソースへのアクセスに関する権限を制御するための仕組みです。
認証された Google アカウント等に対してどんな権限を付与するか (認可) を司る仕組みと考えるとよいでしょう。

IAM の基本的な概念、知識については以下の記事をご参照ください。

blog.g-gen.co.jp

IAM Policy の評価順

IAM のポリシーが評価される際、以下のような順番で評価されます。
明示的な Deny > 明示的な Allow > 暗黙の Deny

Allow ルールも Deny ルールもリソース階層の上から下へ継承されますが、階層のどこかで Deny ルールが記載されていると、これが最も優先されることになります。 これを図にすると、以下のようになります。

IAM Policy 評価フロー

Deny ポリシー詳細

Deny ポリシーについて

Deny ポリシー は IAM Policy (いわゆる Allow ポリシー) とは独立したオブジェクト であり、別で管理されます。
そのため gcloud projects get-iam-policy などでリソースの IAM Policy を確認しても Deny ポリシーは表示されません。

参考として、以下はあるプロジェクトの通常の IAM ポリシーを取得するための gcloud コマンドです。
これを実行しても Deny ポリシーは表示 されません 。
表示されるのはいわゆる Allow ポリシーだけです。

gcloud projects get-iam-policy your-project-name

その代わり以下のようにして、組織/フォルダー/プロジェクトに付与された Deny ポリシーを確認することができます。

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

また Deny ルールの作成には以下のようなコマンドを用います。

gcloud iam policies create my-deny-policy \
    --attachment-point=cloudresourcemanager.googleapis.com/projects/your-project-name \
    --kind=denypolicies
    --policy-file=policy.json

このことから通常の IAM ポリシーの作成や bindings の追加とは異なっており、 Deny ポリシーが通常の IAM ポリシーとは異なるオブジェクト であることが分かります。

Deny ポリシーの閲覧・作成・編集・削除には IAM Role Deny Admin (roles/iam.denyAdmin) が必要です。たとえ Owner (オーナー) ロールを持っていても Deny ポリシーの作成・編集・削除はできないため、ご注意ください (閲覧は可能) 。

Deny ポリシーに関する手順については公式ドキュメント Deny access to resources をご参照ください。

Deny ルールの構成要素

1. 拒否対象の プリンシパル
2. (オプション) 除外するプリンシパル
3. 拒否する パーミッション
4. (オプション) 拒否する 条件 (condition)

上記 1. の「拒否対象の プリンシパル 」とは、 Google アカウントやサービスアカウント、 Google グループ等、 API を実行する主体を指します。
複数のプリンシパルを持つことができます。

上記 2. の「除外するプリンシパル」は 1. で指定したプリンシパルから 除外 するプリンシパルを指します。
例えば 1. で拒否対象プリンシパルとして hogehoge@example.com という Google グループを指定したとします。 2. にて john@example.com というプリンシパルを除外対象として指定すれば、 john が hogehoge グループに所属していても 拒否対象にはなりません 。

上記 3. の「拒否する パーミッション 」は例として cloudresourcemanager.googleapis.com/projects.delete などを指します。
許可ルールでは権限の指定方法として IAM Role を指定 するのに対して Deny ルールでは permission を指定 することに注意が必要です。

上記 4. の「拒否する条件」は、例としてリソースタグ等です。
特定タグを付けたリソースに対する操作だけを、この拒否ルールの対象にできます。

継承

Allow ポリシーと同様に Deny ポリシーも上位リソースから下位リソースに継承されます。

組織レベルで付与したポリシーは下位のフォルダーやプロジェクトに継承されます。
フォルダーレベルで付与したポリシーは下位のプロジェクトに継承されます。
プロジェクトに付与したポリシーは、プロジェクト内の全てのリソースに継承されます。

なお、上位リソースで明示的な Allow ルールで許可された権限を、下位リソースに追加した明示的な Deny ルールで拒否する、といったことも可能です。
前述の通り明示的な Deny が最も強いので、リソース階層の どこかで書かれた明示的な Deny が優先 されます。

IAM 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 が指定されているため、このグループだけはこの Deny の対象外です。とはいえ、明示的な Deny の対象外となるだけですので、このグループが操作を行うには他に 明示的な Allow ルールが必要 です。

deniedPermissions にて、この拒否ルールの対象が cloudresourcemanager.googleapis.com/projects.delete (= プロジェクトを削除する権限) であることが分かります。

denialCondition にて、条件が「env:test」というタグがついているプロジェクトに限られていることが分かります。

Deny ポリシー利用の注意点

ポリシーの評価順は 明示的な Deny > 明示的な Allow > 暗黙の Deny であり、明示的な Deny が最も強いです。

そのためポリシー設計時は 基本的には「明示的な Allow」を付与する/しないで管理することを基本 とし、どうしても強い権限で拒否したい (フタをしたい) ときだけ明示的な Deny を使う、といった手法が良いでしょう。
Deny ポリシーは強力すぎるため、安易に使うと後から修正が難しくなる場合があるためです。

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。

Follow @y_sugi_it