【OCI】IAMポリシーによる権限管理を構文から理解してみた

目次

はじめに

こんにちは！クラウド事業部の中根です。

OCIの権限管理について理解を深めるため、IAMポリシー構文を基に自分なりに理解して、ポイントをまとめてみました。

ポリシー構文の基本知識

※本記事では、アイデンティティ・ドメインありの方を前提としています。

ポリシー構文は以下の通りです。

Allow <subject> to <verb> <resource> in <location> where <conditions>

• 誰が（subject）
• 何を（verb）
• 何に対して（resource）
• どのコンパートメントで（location）
• どんな条件で（conditions）

できるのかを定義しています。
デフォルトでは許可ルールのみですが、拒否ルールを作成することもできるようです。

ポリシー構文の各要素の解説

subject

構文

group '<identity_domain_name>'/'<group_name>' | group id <group_ocid> | dynamic-group '<identity_domain_name>'/'<dynamic-group_name>' | dynamic-group id <dynamic-group_ocid> | any-group | service '<service_name>' | any-user

※ドキュメント上は、any-groupとserviceの間に"|"はなかったですが、誤記と思われます。

• ポイント
  • OCIDでも名前でも指定できる
  • グループと動的グループがある
    • グループは、ユーザーの集合
    • 動的グループは、リソースの集合
  • any-userはなるべく使わない
    • 全ユーザーだけでなく、インスタンスやOCIサービスなどあらゆるリソースも許可されるので、any-groupを使うことが推奨されている模様(参考リンク)
  • ユーザーやグループだけでなく、serviceもsubjectになる
    • OCIマネージドサービスの、他のサービスに対する権限制御ができる。
    • 例：FunctionsサービスがObject Storageを読めるようにする

verb

ポイントは以下の通りです。

• 指定できるのは以下の４つで、下に行くほど権限が強くなる。（inspectでできることはread、use、manageもできる。）
  • inspect
    • 機密情報やユーザー指定のメタデータにはアクセスせずに、リソースをリストする
    • ネットワークの場合は、セキュリティリストやルート表の内容も見れる
  • read
    • いわゆる参照権限
  • use
    • リソースの操作権限
    • 作成や削除はできない。
  • manage
    • すべての権限
  • リソースによっては、微妙に挙動が異なるので注意
    • 詳細はドキュメント参照。
    • 各リソースにおけるinspectやreadが、具体的にできることについてはこちらを参照
• より細かい制御をしたい場合は、verbではなく、conditionsで制御する（request.permission、request.operationなどを利用）
  • 例えば、作成や更新は許可したいからmanageを使うけど、削除だけは拒否したいなど
  • 参考ドキュメント

resource

• リソースの種類
  • 個別のリソースタイプ
    • 各サービスのリソースの一覧はドキュメント参照
  • リソースファミリータイプ
    • 一緒に管理されることが多い複数の個別のリソースタイプのセット
    • 例：VCN、サブネット、ルート表、セキュリティリストなどを含むvirtual-network-family
  • all-resources
    • すべてのリソース

location

構文

tenancy | compartment <compartment_name> | compartment id <compartment_ocid>

• ポイント
  • テナンシかコンパートメントを指定する
  • コンパートメント名だけだと、ポリシーを作成した直下のコンパートメントだけを探すので、そうでない場合はコンパートメント・パスを指定する必要がある。
    • コンパートメント・パスについては以下に書いたのでぜひご覧ください。
      

conditions

ポイントは以下の通りです。

• サポートされている変数等を使い、特定の文字列に完全または部分一致（or不一致）でポリシーの条件を指定できる。
  • 下記例のように、様々な細かい制御ができるようになる
    • タグを使ったアクセス制御
    • IPアドレスでの制御
    • 時間ベースでの制御
    • より細かい動作(verb)レベルでの制御
• 複数条件（AND、OR）の指定も可能。
• 注意点

  • 変数が受信リクエストに適用されない場合、条件はリクエストをfalseとして評価し、リクエストは拒否されます（原文）

  • 例えばconditionsにtarget.group.name != 'Administrators'を指定した場合、ListUsersのようにそもそもtarget.groupが存在しないAPIは、全てfalseになる。verbでuse usersを指定していれば、ListUsersもできるはずですが、target.groupを持っていないので、conditionsの判定でfalseとなり拒否される。

その他知っておくとよさそうなこと

• ポリシーはコンパートメントにアタッチする必要がある
  • 1つのポリシーはどこか1つのコンパートメントに所属するといってもいいかも
• コンパートメントは親コンパートメントに適用されているポリシーを継承する
  • 親コンパートメントで許可されている動作は、その子コンパートメントでも基本的にはできます
  • 権限エラーの時は、親コンパートメントのポリシーもチェックするとよさそうです

参考資料

• https://docs.oracle.com/ja-jp/iaas/Content/Identity/policieshow/Policy_Basics.htm
• https://docs.oracle.com/ja-jp/iaas/Content/Identity/policysyntax/subject.htm
• https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policysyntax.htm
• https://docs.oracle.com/ja-jp/iaas/Content/Identity/policieshow/Verbs.htm
• https://docs.oracle.com/ja-jp/iaas/Content/Identity/policiesgs/policies_topic-ResourceTypes.htm
• https://docs.oracle.com/ja-jp/iaas/Content/Identity/policysyntax/location.htm

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp