Oracle Cloud Infrastructure Documentation

Resource Scheduler IAM Policies

Learn about how to use IAM policies to ensure secure access to Resource Scheduler to create and manage Resource Scheduler schedules and other functionality.

Authentication, Authorization, and Required Policies

Resource Scheduler uses the IAM policies to ensure secure access to Resource Scheduler, to create schedules, and to use schedules to manage resources. Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).

You or another administrator in your organization must set up groups , compartments , and policies  that control user the level and type of access to services and resources. These policies control who can create new users, create and manage the cloud network, create instances, create buckets, download objects, and so on. For more information, see Managing Identity Domains. For specific details about writing policies for each of the different services, see the Policy Reference.

Required Policies

To create and manage schedules, you must create a policy to give users permission to create and change schedules. You must also create a policy to give schedules permission to manage resources.

The following examples show how these policies work.

Example 1. This policy gives users permission to create and modify schedules

Allow the ResourceScheduleUsers group to view and list resource schedules in tenancy.

Allow ResourceScheduleUsers to inspect resource-schedule in tenancy

Example 2

This policy gives the resource schedule permission to perform an action on the target resource.

When a resource schedule is created, by default, it doesn't have permission to perform the action on target resources, so you must give it permission.

The following example allows any user to perform an action on a target resource.

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'}

Non-administrator users who need to use the Oracle Cloud Infrastructure resources that your company owns should contact their administrator to set up their user IDs. Their administrator can confirm which compartment or compartments these users should have access to.

To use any of the Resource Scheduler API operations, you must be authorized in an IAM policy. If you're not authorized, contact the administrator. If you're an administrator who needs to write policies to give users access, see Managing Identity Domains

Resource-Types

The following table lists the resource types used in Resource Scheduler and the permissions REQUIRED to use them.

Resource Types and Permissions
Resource Type Permissions
resource-schedule
  • RESOURCE_SCHEDULE_INSPECT
  • RESOURCE_SCHEDULE_READ
  • RESOURCE_SCHEDULE_CREATE
  • RESOURCE_SCHEDULE_UPDATE
  • RESOURCE_SCHEDULE_MOVE
  • RESOURCE_SCHEDULE_DELETE
resource-schedule-workrequest
  • RESOURCE_SCHEDULE_WORKREQUEST_INSPECT
  • RESOURCE_SCHEDULE_WORKREQUEST_READ

Supported Variables

Resource Scheduler supports all the general variables.

For more information, see General Variables for All Requests and the variables listed in the following table:

Naming Conventions

Variables are lowercase and hyphen-separated.

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

See General Variables for All Requests, plus the variables listed in the following table:

Variable Types and Sources

Variable Types
Type Type Description
String Free-form text
List(Type) List of Entity or String
Entity OCID
Variable Sources
Source Source Description
Request Comes from the request input
Derived Comes from the request
Stored Comes from the service, retained input
Computed Computed from service data

Variables for Every Request

The following table shows required variables, which are supplied by the services for every request.

Resource Scheduler Required Variables
Variable Variable type Description
target.compartment.id ENTITY The OCID of the primary resource for the request
request.operation STRING The operation ID, such as GetUser for the request
target.resource.kind STRING The resource kind name of the primary resource for the request

The following table shows automatic variables, which are supplied by the SDK for every request.

Automatic Variables
Variable Variable type Description

For user-initiated requests:

request.user.id

request.groups.id

 ENTITY

LIST(ENTITY)

 The OCID of the calling user

The OCIDs of the groups of request.user.id
request.principal.group.tag.

<tagNS>.<tagKey

STRING The value of each tag on a group of which the principal is a member
request.principal.compartment.tag.

<tagNS>.<tagKey

STRING The value of each tag in a compartment of which the principal is a member

The following table shows dynamic variables, which are computed implicitly by IAM AuthZ.

Dynamic Variables
Variable Variable type Description
request.principal.group.tag.<tagNS>.<tagKey> STRING

The value of each tag on a group of which the principal is a member.
request.principal.compartment.tag.<tagNS>.<tagKey STRING The value of each tag on the compartment that contains the principal.
target.resource.tag.<tagNS>.<tagKey> STRING

The value of each tag on the target resource. (Computed based on tagSlug supplied by service on each request.)
target.resource.compartment.tag.<tagNS>.<tagKey> STRING

The value of each tag on the compartment that contains the target resource.

Details for Verb + Resource-Type Combinations

The following tables show the permissions and API operations covered by each verb. The level of access is cumulative as you go from inspect > read > use > manage. A plus sign (+) in a table cell indicates incremental access compared to the cell directly above it, whereas "no extra" indicates no incremental access.

For details of the permissions, see Permissions.

Permissions Required for Each API Operation

List the operation specific attributes that you make available to the policy compiler. For a specific resource kind, you must have the same set of attributes across all tasks (get, list, delete, and more). The one exception is for the Create task, where you don't have the ID for that object yet, so you can't have a target.RESOURCE-KIND.id attribute for Create.

For information about permissions, see Permissions.

The following table lists the Resource Scheduler API operations in a logical order, grouped by resource type.

Permissions Required for Each Resource Scheduler API Operation
API Permissions Required to Use the Operation Operation
ListSchedules RESOURCE_SCHEDULE_INSPECT Return a list of resource schedules.
GetSchedule RESOURCE_SCHEDULE_READ Get a resource schedule.
CreateSchedule RESOURCE_SCHEDULE_CREATE Create a resource schedule.
UpdateSchedule RESOURCE_SCHEDULE_UPDATE Update a resource schedule.
DeleteSchedule RESOURCE_SCHEDULE_DELETE Delete a resource schedule.
ChangeScheduleCompartment RESOURCE_SCHEDULE_MOVE Change resource schedule compartment
ListWorkRequests RESOURCE_SCHEDULE_WORKREQUEST_INSPECT List work requests associated with a resource schedule.
GetWorkRequest RESOURCE_SCHEDULE_WORKREQUEST_READ Get a work request.

Metaverb Map

Metaverb Map
Resource type Inspect Read Use Manage
RESOURCE-SCHEDULE RESOURCE_SCHEDULE_INSPECT RESOURCE_SCHEDULE_READ none
  • 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 none none

Example Policies

You can use these example policies as templates to create and manage (create, delete, activate, and others) your own Resource Scheduler policies.

Note

To use resource schedules, you must create a policy to give users permission to create a schedule and you must create a policy to give a schedule permission to manage resources.

Example 1

This policy gives users permission to manage resource schedules in their tenancy.

This example allows a named user group to manage resource schedules throughout the tenancy:

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

For example:

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

Example 2

This policy gives users permission to manage resource schedules in a specific compartment.

The following example allows a group to manage resource schedules in a named compartment:

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

For example:

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

Example 3

This policy gives a resource schedule permission to perform an action on a resource.

When a resource schedule is created, by default, it doesn't have permission to perform the action on target resources, You dc must give it permission.

This policy gives a schedule permission to manage predefined resources such as instances in a compartment.

The following example allows a user to manage a resource type in a compartment where 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>'}

For example:

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'}

Example 4

This example policy shows how to grant a resource-schedule permission to perform an action as a dynamic group.

First, create a Dynamic Group to identify the resources that you want to authorize access for. The dynamic group requires one or more matching rules, as shown in the following example.

The following example shows how to create a dynamic group for resource-scheduler named resource-scheduler-dynamic-group:

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

Then, setup proper policies.

The following example show how to allow dynamic-group resource-scheduler-dynamic-group to manage functions-family in tenancy:
Allow dynamic-group resource-scheduler-dynamic-group to manage functions-family in tenancy