これまで、OCIのIAMポリシーではプリンシパルに対して何らかの権限を許可（Allow）していくタイプの権限付与のみを行うことができましたが、あらたなIAMポリシー構文として拒否ポリシー（Deny Policy）が登場しました。
管理者側から一括でユーザーに対してなんらかの権限を制限したいような場合に利用できそうです。
ドキュメントの内容を確認しながら、実際に試してみます。
-
ドキュメント：Deny Policies
テナンシでDenyポリシーの有効化
Denyポリシーはデフォルトでは無効化されています。利用するためにはテナンシレベルで有効化を行う必要があり、一度有効化すると無効化はできません。
Default Identity DomainのAdministratorsグループのメンバーのみがコンソール上で有効化作業を実施できます。
-
メニュー「アイデンティティとセキュリティ」→「ポリシー」を表示し、「アクション」から「ポリシー設定」を選択
-
「IAM拒否ポリシーの有効化」のトグルをクリック
-
「IAM拒否ポリシーの有効化の確認」の注意書きがポップアップするので、内容を確認して「有効化」をクリック。（コンソールの注意書きにはもとに戻せないとは書いてないので注意。）
- 全てのユーザーがDenyステートメントを作成できないようにするデフォルトのDenyポリシーが自動的に作成される。
- Default DomainのAdministratorsグループ、もしくはこの操作を行ったユーザーのみがDenyポリシーを作成、管理することができる。
-
有効化が成功
-
自動的に「IAMDenyPolicy」というポリシーが作成され、ポリシーのページにリダイレクトされます。
-
ステートメントは以下の1つのみ記載されています。
-
deny any-user to manage policies in tenancy where all {target.policy.type = 'deny', request.principal.id != 'ocid1.user.oc1..aaaaaaaa3lbyx2nrbuqcgu23rpj5hoeuw4dvtmrmc23tjngd6rqhtayrkgaa'}
有効化したユーザーのOCIDだけを除外し、他のユーザーはdenyポリシーは作成できないというポリシーになっています。
また、このポリシーの有無にかかわらず、Default DomainのAdministratorsグループのユーザーは常に拒否ポリシーの適用対象外となっています。
つまり、テナンシレベルで有効化を行ってもデフォルトでは管理者以外はDenyポリシーを作成することはできないようになっています。また、管理者は常にDenyポリシーの影響を受けないようになっています。あやまったDenyポリシーを作成してしまって管理者ですら操作ができなくなってしまうことや、既存の権限設定に影響を与えることを防ぐためです。
以上で有効化の作業は完了です。
Denyポリシー作成前後での動作確認
前提：テスト用のユーザー testuser をグループ testgroup に所属させ、以下のAllowポリシーでtestgroupにhandsonコンパートメントのmanage all-resources権限を付与している状態です。また、Cloud Shellの利用権限も与えています。
allow group testgroup to manage all-resources in compartment handson
Denyポリシー作成前のオブジェクトストレージ操作
-
testuserでコンソールからオブジェクト・ストレージのバケットにオブジェクトをアップロードし、CLIでダウンロードしてみます。
-
問題なくアップロード、ダウンロードができることが確認できました。
Denyポリシー作成
-
管理者ユーザーで以下のDenyポリシー文を追加します。既存のAllow文に変更は加えていません。
deny group testgroup to manage objects in tenancy
Denyポリシー作成後のオブジェクトストレージ操作(Manageを拒否)
-
testuserでさきほどと同じくオブジェクトのアップロードを試します。
-
以下のエラーで失敗しました。AllowのポリシーよりもDenyのポリシーのほうが優先されるため、objectのmanageを必要とするアップロード作業はできなくなったことがわかりました。
APIエラー Either the bucket named 'test_bucket' does not exist in the namespace 'xxxxxxxxxxx' or you are not authorized to access it. (BucketNotFound).
-
ただしオブジェクトのダウンロードは引き続き可能です。オブジェクトのreadは拒否していないためです。
-
Denyポリシー作成後のオブジェクトストレージ操作(Readを拒否)
-
次に、管理者ユーザーでDeny文を編集して、readを拒否します。
-
変更前：
deny group testgroup to manage objects in tenancy -
変更後：
deny group testgroup to read objects in tenancy
-
-
testuserで先ほどと同様にオブジェクトのアップロードとダウンロードを試します。
-
アップロードは先ほどと同じエラーで失敗しました。
-
今回はダウンロードも同じく失敗しました。ダウンロードするにはReadが必要なためです。
-
ただし、listコマンドは成功します。これは、listに必要なinspectは拒否されていないためです。
以上のことから、IAMポリシーの動詞に関してはドキュメントに記載されている通り以下のとおりであることが実際に確認できました。
- IAMポリシーの動詞は累積的で、Manage > Use > Read > Inspect の順でより多くの（強い）権限が含まれています。
- Allow文の場合は上位の動詞を許可すれば下位の動詞も必ず含まれることになります。つまり、Manageを許可すればUse, Read, Inspectの内容もすべて許可されていることになります。
- Deny文の場合は逆で、下位の動詞を拒否すれば上位の動詞も含まれることになります。たとえばReadを拒否すればその上位のUseやManageも拒否されますが、Inspectは拒否されません。 これによって、読み取りまではできるけれど作成や削除をさせたくない、あるいは、リスト表示まではできるけれどリソースの内容の参照はさせたくない、といったケースに対応することができます。
- 詳細：ドキュメント Metaverb Inversion
今回、Denyポリシーの基本的な動きは確認できました。AllowよりもDenyは優先されるため、もし利用する際には誤って必要な権限まで剥奪してしまわないように十分に注意しながら設定していく必要があると感じました。