はじめに

IAMを操作していたところ、権限を付与する際に、基本ロールはもちろんですが、
事前定義ロールでも範囲が広いようなケースもあると思い、絞る方法を確認してみました。

IAM Roleの基本的な部分のおさらい

概要

IAMに対しては基本的にRoleを付与する形になり、ポリシーを直接付与するようなことはありません。
大きく基本ロール、事前定義ロール、カスタムロールがありまして、それぞれの役割に軽く触れます。

Role種別

基本ロール
- 少ないので具体的に書くと、オーナー、編集者、閲覧者がある。
  - 位置づけ的には、オーナーがadmin、編集者がPowerUserっぽい、閲覧者がReadOnly
    - PowerUserという表現はちょっと過大でもう少し権限が絞られているので、それプラス事前定義ロールを割り当てていたりすることもある
事前定義ロール
- 基本ロールはサービス全体に対する権限だったが、一つのサービスに対して実施した役割に応じて分けられているようなイメージ
- 基本ロールもだがGoogleにて管理され、新たなサービスなどが加わった場合、事前定義ロールの内容も入れ替わる
- 下位互換性がないものはベータ版やアルファ版と呼ばれ、本番環境での適用が推奨されておらず、本番環境では一般提供されているものを適用することが推奨されている
カスタムロール
- 各Roleに含まれる権限を用途や役割に合わせて自身でRoleを作成することが可能
- 計画的に組み込めない場合や管理が行き届かない何でもコミコミみたいになってしまいそう

Roleの付与

基本ロールでは範囲が広い部分もあるので最終的には事前定義ロールのみで構成できると良いと思います。
ただ、対応するプロジェクトの要件によって、権限の範囲は変わってくるので、最初は基本ロールを割り当てないと
プロジェクトの進捗に影響が出る場合もあると思うので、要件や状況に応じた実装が必要となります。
基本ロールで割り当てた場合でも、以下の赤枠箇所のように割り当てた権限に対してどの程度利用されているかが確認できるので、
それをもとに事前定義ロール、カスタムロール、そのまま基本ロール等、あとから検討するような方法もあるのかな、と思います。

既に設定したRoleの権限を絞る(制限する)方法

ここからがもともと書きたかった部分です。

拒否ポリシー

まだプレビュー機能ですが、拒否ポリシーという機能があります。これを利用することで適用していたRoleの中でも実行させたくない権限をプリンシパル単位で、拒否ポリシーとして制御することが可能です。

概要

必要なRoleを付与

以下対象RoleをIAMに付与します。
対象：拒否管理者（roles/iam.denyAdmin）
ポリシー内容：拒否ポリシーを表示、作成、更新、削除する:

ポリシーを定義する

拒否ポリシーは以下のようにどのプリンシパルに対してどの権限を拒否する、
というような形で定義することが可能です。

{
  "displayName": "POLICY_NAME",
  "rules": [
    {
      "denyRule": DENY_RULE_1
    },
    {
      "denyRule": DENY_RULE_2
    },
    {
      "denyRule": DENY_RULE_N
    }
  ]
}

例

{
  "displayName": "XXXXXXXXX",
  "rules": [
    {
        "denyRule": {
            "deniedPrincipals": [
                # 対象プリンシパル(ユーザやサービスアカウントなど)
                "principal://iam.googleapis.com/projects/-/serviceAccounts/サービスアカウントメールアドレス"
            ],
            "deniedPermissions": [
                # 対象権限
                "storage.googleapis.com/buckets.list"
            ]
        }
    }
  ]
}

拒否可能な対象の権限は以下になります。
https://cloud.googles.ltd/iam/docs/deny-permissions-support?hl=ja

ポリシーを作成する

作成コマンドを実行します。

gcloud beta iam policies create POLICY_ID \
    --attachment-point=ATTACHMENT_POINT \
    --kind=denypolicies \
    --policy-file=POLICY_FILE

結果を以下で確認することができます。

gcloud beta iam policies get POLICY_ID \
    --attachment-point=ATTACHMENT_POINT \
    --kind=denypolicies \
    --format=json

本来、このあと動作を確認し拒否されることを確認します。

所感

事前定義ロールでも様々なロールで分かれているので問題ないかもしれませんが、
手順も難しくなくポリシー内容も明快なので、今後柔軟なポリシーを組む上では、
GAが待たれる機能の一つではないか、と思います。
ガードレールな使い方ができるものだと思うので、欲しい機能なのかな、と思いました。