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

記事タイトルとURLをコピーする

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

2022/03/03 に Deny policy が Preview 公開されました。この公開前までは IAM Policy には Allow しか書くことができませんでしたが、この機能でそれが改善されます。
当記事では、この Deny policy について解説していきます。

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

なお注意点として 「明示的な Deny」の機能は 2022/03 月現在 Preview 公開 です。
Preview 版においては「サポートの制限」「仕様の変更の可能性」「SLA 無し」など 各種制限 があります。本番環境での使用は想定されておりませんので、気をつけましょう。 Preview 期間が終わり GA (一般公開) されるまでは、本番環境での利用は控えるべきです。

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 beta iam policies get my-deny-policy  \
    --attachment-point=cloudresourcemanager.googleapis.com/projects/your-project-name \
    --kind=denypolicies

# または

gcloud beta projects get-ancestors-iam-policy sugimura --include-deny

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

gcloud beta 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) が必要です。
2022/03 の Preview 公開時点では 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 というプリンシパルを除外対象として指定すれば、 johnhogehoge グループに所属していても 拒否対象にはなりません

上記 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 ポリシーは強力すぎるため、安易に使うと後から修正が難しくなる場合があるためです。

杉村 勇馬 (記事一覧) (Facebook)

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

元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格10冠。

2022年5月現在、ハマっているものはモンスターエナジーウルトラ。