Oracle Cloud Infrastructureドキュメント

リソース・スケジューラのIAMポリシー

IAMポリシーを使用して、リソース・スケジューラへのセキュアなアクセスを確保し、リソース・スケジューラ・スケジュールおよびその他の機能を作成および管理する方法について学習します。

認証、認可および必要なポリシー

リソース・スケジューラは、IAMポリシーを使用して、リソース・スケジューラへのセキュアなアクセス、スケジュールの作成、およびスケジュールを使用したリソースの管理を行います。Oracle Cloud Infrastructureの各サービスは、すべてのインタフェース(コンソール、SDKまたはCLI、およびREST API)で、認証および認可のためにIAMと統合されます。

組織内のユーザーまたは別の管理者は、サービスやリソースへのアクセスのレベルとタイプを制御するグループ、コンパートメントおよびポリシーを設定する必要があります。これらのポリシーにより、新規ユーザーの作成、クラウド・ネットワークの作成と管理、インスタンスの作成、バケットの作成、オブジェクトのダウンロードなどを実行できるユーザーが制御されます。詳細は、アイデンティティ・ドメインの管理を参照してください。異なる各サービスに対するポリシーの記述の詳細は、ポリシー・リファレンスを参照してください、

必要なポリシー

スケジュールを作成および管理するには、スケジュールを作成および変更する権限をユーザーに付与するポリシーを作成する必要があります。また、リソースを管理するためのスケジュール権限を付与するポリシーを作成する必要があります。

次の例に、これらのポリシーの仕組みを示します。

例1.このポリシーは、スケジュールを作成および変更する権限をユーザーに付与します

ResourceScheduleUsersグループにテナンシのリソース・スケジュールの表示およびリストを許可します。

Allow ResourceScheduleUsers to inspect resource-schedule in tenancy

例2

このポリシーは、ターゲット・リソースに対してアクションを実行するリソース・スケジュール権限を付与します。

リソース・スケジュールが作成されると、デフォルトでは、ターゲット・リソースに対してアクションを実行する権限がないため、リソース・スケジュールに権限を付与する必要があります。

次の例では、任意のユーザーがターゲット・リソースに対してアクションを実行できます。

Allow any-user to manage <resource_type (instance, database, and others)> in compartment id <target_compartment_ocid> where all {request.principal.type='resourceschedule',request.principal.id='ocid_of_resourceschedule'}

企業が所有するOracle Cloud Infrastructureリソースを使用する必要がある管理者以外のユーザーは、管理者に連絡してユーザーIDを設定する必要があります。管理者は、これらのユーザーがアクセス権を持つコンパートメントを確認できます。

リソース・スケジューラAPI操作を使用するには、IAMポリシーで認可されている必要があります。権限がない場合は、管理者に連絡してください。ユーザーにアクセス権を付与するポリシーを記述する必要がある管理者の場合は、アイデンティティ・ドメインの管理を参照してください

リソース・タイプ

次の表に、リソース・スケジューラで使用されるリソース・タイプと、リソース・スケジューラを使用するために必要な権限を示します。

リソース・タイプおよび権限
リソース・タイプ 権限
リソース- スケジュール
  • RESOURCE_SCHEDULE_INSPECT
  • RESOURCE_SCHEDULE_READ
  • RESOURCE_SCHEDULE_CREATE
  • RESOURCE_SCHEDULE_UPDATE
  • RESOURCE_SCHEDULE_MOVE
  • RESOURCE_SCHEDULE_DELETE
リソース- スケジュール- 作業リクエスト
  • RESOURCE_SCHEDULE_WORKREQUEST_INSPECT
  • RESOURCE_SCHEDULE_WORKREQUEST_READ

サポートされる変数

リソーススケジューラでは、すべての一般的な変数がサポートされます。

詳細は、すべてのリクエストの一般変数および次の表に示す変数を参照してください。

命名規約

変数は小文字で、ハイフン区切りです。

target.tag-namespace.name # "name"indicates a unique key
target.display-name # "display-name"indicates a non-unique description

「すべてのリクエストの一般的な変数」および次の表に示す変数を参照してください。

変数タイプとソース

変数型
タイプ タイプの説明
文字列。 自由形式のテキスト
リスト(タイプ) エンティティまたは文字列のリスト
エンティティ OCID
変数ソース
ソース ソースの説明
要求 リクエスト入力から取得されます。
導出済 リクエストから取得されます
格納済 サービスから取得され、入力は保持されます。
計算済 サービス・データから計算されます

すべてのリクエストに対する変数

次の表に、リクエストごとにサービスによって提供される必須変数を示します。

リソース・スケジューラの必須変数
変数 変数タイプ 内容
target.compartment.id ENTITY リクエストのプライマリ・リソースのOCID
request.operation STRING リクエストの操作ID (たとえば、GetUser)
target.resource.kind STRING リクエストのプライマリ・リソースのリソース種類名

次の表に、リクエストごとにSDKによって提供される自動変数を示します。

自動変数
変数 変数タイプ 摘要

ユーザーが開始したリクエストの場合:

request.user.id

request.groups.id

 ENTITY

LIST(ENTITY)

 コール・ユーザーのOCID

request.user.idのグループのOCIDs
request.principal.group.tag.

<tagNS>.<tagKey

STRING プリンシパルがメンバーであるグループの各タグの値
request.principal.compartment.tag.

<tagNS>.<tagKey

STRING プリンシパルをメンバーとするコンパートメント内の各タグの値

次の表に、IAM AuthZによって暗黙的に計算される動的変数を示します。

ダイナミック変数
変数 変数タイプ 摘要
request.principal.group.tag.<tagNS>.<tagKey> STRING

プリンシパルがメンバーであるグループの各タグの値。
request.principal.compartment.tag.<tagNS>.<tagKey STRING プリンシパルを含むコンパートメントの各タグの値。
target.resource.tag.<tagNS>.<tagKey> STRING

ターゲット・リソースの各タグの値。(各リクエストでサービスによって提供されるtagSlugに基づいて計算されます。)
target.resource.compartment.tag.<tagNS>.<tagKey> STRING

ターゲット・リソースを含むコンパートメントの各タグの値。

動詞+リソース・タイプの組合せの詳細

次の表は、各動詞でカバーされる権限およびAPI操作を示しています。アクセス・レベルは、inspect > read > use > manageの順に累積します。表のセルのプラス記号(+)は、そのすぐ上のセルと比較して増分アクセスを示しますが、「追加なし」は増分アクセスを示しません。

権限の詳細は、「権限」を参照してください。

API操作ごとに必要な権限

ポリシー・コンパイラで使用可能にする操作固有の属性をリストします。特定のリソース・タイプの場合、すべてのタスク(取得、リスト、削除など)で同じ属性セットを持つ必要があります。1つの例外はCreateタスクに関するものであり、そのオブジェクトのIDはまだないため、Createのtarget.RESOURCE-KIND.id属性はありません。

権限の詳細は、権限を参照してください。

次の表は、リソース・スケジューラAPI操作を論理的な順序で、リソース・タイプ別にグループ化したものです。

各リソース・スケジューラAPI操作に必要な権限
API 操作の使用に必要な権限 工程
ListSchedules RESOURCE_SCHEDULE_INSPECT リソース・スケジュールのリストを返します。
GetSchedule RESOURCE_SCHEDULE_READ リソース・スケジュールを取得します。
CreateSchedule RESOURCE_SCHEDULE_CREATE リソース・スケジュールを作成します。
UpdateSchedule RESOURCE_SCHEDULE_UPDATE リソース・スケジュールを更新します。
DeleteSchedule RESOURCE_SCHEDULE_DELETE リソース・スケジュールを削除します。
ChangeScheduleCompartment RESOURCE_SCHEDULE_MOVE リソース・スケジュール・コンパートメントの変更
ListWorkRequests RESOURCE_SCHEDULE_WORKREQUEST_INSPECT リソース・スケジュールに関連付けられた作業リクエストをリストします。
GetWorkRequest RESOURCE_SCHEDULE_WORKREQUEST_READ 作業リクエストを取得します。

メタバーマップ

メタバーマップ
リソース・タイプ インスペクト 読取り 使用 管理
RESOURCE-SCHEDULE RESOURCE_SCHEDULE_INSPECT RESOURCE_SCHEDULE_READ なし
  • RESOURCE_SCHEDULE_CREATE
  • RESOURCE_SCHEDULE_UPDATE
  • RESOURCE_SCHEDULE_UPDATE
  • RESOURCE_SCHEDULE_MOVE
  • RESOURCE_SCHEDULE_DELETE
RESOURCE-SCHEDULE-WORKREQUEST RESOURCE_SCHEDULE_WORKREQUEST_INSPECT RESOURCE_SCHEDULE_WORKREQUEST_READ なし なし

サンプル・ポリシー

これらのサンプル・ポリシーをテンプレートとして使用して、独自のリソース・スケジューラ・ポリシーを作成および管理(作成、削除、アクティブ化など)できます。

ノート

リソース・スケジュールを使用するには、ユーザーにスケジュールを作成する権限を付与するポリシーを作成する必要があります。また、リソースを管理するスケジュール権限を付与するポリシーを作成する必要があります。

例1

このポリシーは、テナンシのリソース・スケジュールを管理する権限をユーザーに付与します。

この例では、名前付きユーザー・グループがテナンシ全体でリソース・スケジュールを管理できます:

Allow group <group_name> to manage resource-schedule-family in tenancy

たとえば:

Allow group YourResourceScheduleAdminGroup to manage resource-schedule-family in tenancy

例2

このポリシーは、特定のコンパートメントのリソース・スケジュールを管理する権限をユーザーに付与します。

次の例では、グループは名前付きコンパートメントのリソース・スケジュールを管理できます:

Allow group <group_name> to manage resource-schedule-family in compartment <compartment_name>

たとえば:

Allow group ResourceScheduleAdmins to manage resource-schedule-family in compartment ResourceScheduleCompartment

例3

このポリシーは、リソースに対してアクションを実行するリソース・スケジュール権限を付与します。

リソース・スケジュールが作成されると、デフォルトでは、ターゲット・リソースに対してアクションを実行する権限がありません。リソース・スケジュールに権限を付与する必要があります。

このポリシーは、コンパートメント内のインスタンスなどの事前定義済リソースを管理するためのスケジュール権限を付与します。

次の例では、ユーザーがall{request.principal.type='resourceschedule',request.principal.id='<ocid_of_resourceschedule>のコンパートメント内のリソース・タイプを管理できるようにします:
Allow any-user to manage <resource_type> in compartment id <compartment_ocid> where all{request.principal.type='resourceschedule',request.principal.id='<ocid_of_resourceschedule>'}

たとえば:

Allow any-user to manage instance in compartment id ocid.compartment.oc1...q7fa where all{request.principal.type='resourceschedule',request.principal.id='ocid.resourceschedule.oc1.iad.axgr...dt8zb'}

例4

このポリシー例は、動的グループとしてアクションを実行するためのリソース・スケジュール権限を付与する方法を示しています。

最初に、アクセスを許可するリソースを識別する動的グループを作成します。次の例に示すように、動的グループには1つ以上の一致ルールが必要です。

次の例は、resource-scheduler-dynamic-groupという名前のリソース・スケジューラに対して動的グループを作成する方法を示しています。

ALL {resource.type='resourceschedule', resource.id='ocid.resourceschedule.oc1.iad.axgr...dt8zb'}

次に、適切なポリシーを設定します。

次の例は、dynamic-group resource-scheduler-dynamic-groupがテナンシでfunctions-familyを管理できるようにする方法を示しています:
Allow dynamic-group resource-scheduler-dynamic-group to manage functions-family in tenancy