基本情報
今回はIAMポリシーについて考えてみます。公式リンク
基本的にOCIで各リソースに対する操作権限を管理する為に、IAMポリシーを設定することになります。
設定例
IAMポリシーはIAMグループに対して設定し(下図①)、設定されたIAMグループにIAMユーザーを所属させてリソースを操作できるようになる(②)、という流れです。
下図は本番用と開発用の2つのコンパートメントで権限を分け、それぞれのグループを作成した例です。
-
①本番用グループに本番用コンパートメントを操作する権限を付与
同様に開発用グループに開発用コンパートメントを操作する権限を付与 -
②ユーザーBを本番用グループに追加すると本番用コンパートメントを操作できるようになる。
ユーザーは複数のグループに所属することが可能なため、開発用グループに追加することで開発用コンパートメントを使用することも可能になる
ポリシー作成画面
[アイデンティティとセキュリティ]から[ポリシー]を選択すると作成画面になります。
ポリシーの作成に関してはユースケースなどを、リストから選んでポリシーが作成できる、ポリシービルダーの使用と
手動エディタでポリシー構文を記載する方法があります。
ポリシービルダーの方が簡単にポリシーを作成できそうですが、下記の懸念点があります。
- ポリシー内に構文を追加する場合は手動エディタしか利用できない点
- 実際にポリシーの内容を後から確認する際には構文を理解する必要がある点
上記を踏まえて、私は手動エディタに慣れておいた方がよいと考えています。
ポリシー構文
ポリシーを作成する際の構文は下記のような形です。
1 |
Allow [subject] to [verb] [resource-type] in [location] where [conditions] |
上記設定例にある本番用ポリシーは下記のようなものになります。
1 |
Allow group 本番用グループ to manage all-resources in compartment 本番用コンパートメント |
上記はあくまで例になりますので、実際はグループ名やコンパートメント名に日本語は使用できないのでご注意ください。
下記は覚えておくとよいかもしれません。
- 基本的に構文はAllow(許可)からはじまる。Deny(拒否)は設定できない
- IAMユーザーはグループに所属させないと作成時は権限は一切持たない
- IAMユーザーは複数のグループに所属出来る
- グループにどのようのなポリシーが適用されているかはポリシーの構文から確認する必要がある
構文に利用する項目はそれぞれ下記のような意味合いを持ちます。
- subject: ポリシーを付与される対象(グループや動的グループ)
- verb: ポリシーによって利用可能となる操作(manage,use,list,inspectを選択可能。詳細は下記に補足)
- resource-type: ポリシーによって利用可能となるリソース(全てのリソースやコンピュート等個別に指定可能)
- location: ポリシーの影響範囲(テナンシやコンパートメント)
- conditions: ポリシーを適用する際の条件(特定の名前のグループだけを指定等)
verb
公式ページでは下記のような説明となっております。
例えば「あるグループにはコンピュートインスタンスをコンソールから利用(停止・起動)出来るようにしたいが、新規作成や削除をさせたくない」という場合はuseを設定するといった形の利用が出来ます。
注意が必要な点として、対象のOCIリソースによって挙動に違いがあります。
例えばネットワーキング・リソースではルートテーブルやセキュリティリストの更新などはuseで利用できそうなイメージを持ちますが、実際はmanage権限が必要になります。
そのようなケースもありますので、ポリシーを作成する際に、resource-typeで細かく設定をする場合は、公式ページより対象リソースで操作に必要となる権限を確認してください。
まとめ
今回はIAMポリシーについて簡単に確認してみました。
セキュリティに関して、厳しく設定をしていくとなるとポリシーも複雑になるかと思います。
どういったポリシーを作成し、どのグループに設定するかなど情報は纏めておくとよいでしょう。
今後のアップデートでグループ側から適用されているポリシーがわかるようになる機能が欲しいですね。