Identity and Access Management Overview

4 Identity and Access Management Overview

The Identity and Access Management service (IAM) lets you control who has access to the cloud resources within your tenancies. It is the task of a tenancy administrator to control what type of access a user group has, and to which specific resources that access applies. The responsibility to manage and maintain access control can be delegated to other privileged users, for instance by granting them full access to a subcompartment of the tenancy.

Appliance administrator accounts are managed separately and provide access to appliance administration functions. This functionality is not related to the tenancy-level IAM service. For more information, refer to the section Administrator Access.

Users and Groups

When a tenancy is created, a default user account is added to allow you to log in and perform initial setup tasks. This default user is included in a group named Administrators, which provides full access to all resources and operations within the tenancy. The group cannot be deleted and must always contain at least one user.

Once logged in, the tenancy administrator can start adding more users and organize them into groups. A group is a set of users who have the same type of access to a particular set of resources. The general principle is that users have no access rights at all, unless they have been explicitly granted permission.

User accounts can be created locally in the tenancy, but Private Cloud Appliance also supports federating with an existing identity provider. In this configuration, a tenancy administrator sets up a federation trust relationship between the tenancy and the identity provider, allowing users log in with their existing id and password. Each existing user group from the identity provider can be mapped to a group in the tenancy, so that existing group definitions can be re-used to authorize access to cloud resources. For more information, see Federating with Identity Providers.

The permission to access a resource and perform an operation is defined in a policy. The policy for the Administrators group states that the users in this group are allowed to manage all resources in the tenancy. For all other user groups as well, a policy must be defined to manage their specific permissions. For more information, see How Policies Work.

To group and isolate resources, you organize them into compartments. Compartments are primary building blocks in a tenancy. You can compare them to the directories in a file system structure, where the tenancy is equivalent to the root directory. Compartments also help control and secure the access to resources. Unlike administrators, regular users only see the compartments to which they have access. Policy statements further refine the type of access. For more information, see Organizing Resources in Compartments.

As an example of how users, groups, compartments, resources and policies interact with each other, consider the following scenario. You decide to create groups for different teams in your organization and assign a separate compartment for each team's resources. You allow each team to create and use instances within their compartment but prevent them from accessing the resources of another team. In addition, you might prefer to let a network administrator manage all network resources in the tenancy. To achieve this, you create all network-related resources in a dedicated network compartment, which only a network administrator is allowed to manage. Other users need to be allowed to use the network resources in their configurations, but they should not have permission to modify the network setup.

User Credentials

Different types of credentials are managed through the Identity and Access Management (IAM) service:

Account password: for signing in to the Compute Web UI to work with cloud resources in the tenancy. Note that passwords for federated users are not managed through IAM because the identity provider controls their login activity.
API signing key: for sending API requests, which require authentication. These keys must be created in PEM format.

Account Passwords

When creating a new user account, the tenancy administrator generates a one-time password and delivers it to the user in a secure way. When users sign in for the first time, they are prompted to change this password. After 7 days the one-time password expires and an administrator will need to generate a new one.

After signing in successfully with the new password, users can start working with cloud resources in the tenancy, in accordance with the permissions they have been granted.

All users are allowed to change their own password, which can be done through the Compute Web UI. Users who forgot their password must request a tenancy administrator to reset the password for them.

After 10 unsuccessful login attempts in a row, a user is automatically locked out of the system. A tenancy administrator needs to unblock the account.

API Signing Keys

Users who need to make API requests must have an RSA public key added to their user profile. Both the private and public key must be in PEM format, with a minimum length of 2048 bits. Users either generate a private/public key pair through the Compute Web UI and download the private key, or generate the key pair on their local machine and upload the public key to their profile.

Alternatively, a tenancy administrator can generate the API keys and complete the profile setup for all users. This is a requirement for non-human user accounts: systems that make API requests without human operation. For such systems, the administrator needs to create a user account with signing keys, but without password.

On the system from where API requests are sent, a directory named .oci must be created inside the user home directory. The .oci directory must contain a configuration file with required parameters for interaction with the API server. Make sure it lists the correct path to where the private key file is stored, if it is not in the same directory. API requests are signed using the private key.

A user account can contain a maximum of 3 API signing keys at a time. API signing keys are different from the SSH keys you use to access a compute instance.

Federating with Identity Providers

Many companies use an identity provider to manage user logins and passwords and to authenticate users for access to secure websites, services, and resources. To access the Private Cloud Appliance Compute Web UI, people must also sign in with a user name and password. An administrator can federate with a supported identity provider so that each user can use an existing login and password, rather than having to create new credentials to access and use cloud resources.

Federation involves setting up a trust relationship between the identity provider and Private Cloud Appliance. When the administrator has established that relationship, any user who goes to the Compute Web UI is prompted with a single sign-on experience offered by the identity provider.

Supported Identity Providers

For identity federation, Private Cloud Appliance supports the Security Assertion Markup Language (SAML) 2.0 protocol. However, the only identity provider supported in version 3.0.1 is Microsoft Active Directory, via Active Directory Federation Services.

Your organization can have multiple Active Directory accounts; for example one for each division of the organization. You can federate multiple Active Directory accounts with Private Cloud Appliance, but each federation trust that you set up must be for a single Active Directory account. Identity federation is available in the Compute Web UI as well as the Service Web UI.

Private Cloud Appliance version 3.0.1 does not currently support the System for Cross-domain Identity Management (SCIM), a standard protocol that enables user provisioning across identity systems. Without SCIM, user accounts from an identity provider cannot be automatically provisioned in a tenancy and synchronized. Consequently, the credentials of federated users cannot be managed within the tenancy.

Experience for Federated Users

When browsing to the Compute Web UI, the user is prompted to enter the name of the tenancy. Federated users then choose which identity provider to use, and are redirected to the identity provider's sign-in interface for authentication. After entering the user name and password that they already set up, they are authenticated by the identity provider, and redirected back to the Private Cloud Appliance Compute Web UI. From here, they can access the resources in their tenancy, in accordance with the permissions granted to them.

Federated user accounts are created and managed within the identity provider; they are not replicated or synchronized within Private Cloud Appliance. Federated users are granted access based on their membership of identity provider groups that are mapped to Private Cloud Appliance groups in the tenancy. Unlike local users, federated users cannot manage their credentials through the Compute Web UI. They have no User Settings page, cannot change or reset their password, and cannot upload API signing keys to use the API and CLI.

Federation Process Overview

To set up the federation trust between Private Cloud Appliance and an identity provider, you perform certain steps of the procedure on both systems respectively. In general, identity federation consists of these steps:

Configuring groups in the identity provider, so they can be mapped to groups in the Private Cloud Appliance tenancy.
Downloading the SAML metadata document from the identity provider and collecting the names of the groups you intend to map.
Setting up the new identity provider in your Private Cloud Appliance tenancy. You need to upload the identity provider metadata file. Create the group mappings at this stage, or return to add them later.
Downloading the Private Cloud Appliance federation metadata document from the Federation page in your tenancy.
Setting up Private Cloud Appliance as a trusted application or trusted relying party in your identity provider. You need to upload the Private Cloud Appliance federation metadata document, or provide the URL to it.

The identity provider SAML authentication response must be configured to include name ID and groups, which are parameters required by Private Cloud Appliance.
Setting up IAM policies for the mapped groups.
Providing federated users the name of the tenancy and the URL to the Private Cloud Appliance Compute Web UI.

Organizing Resources in Compartments

After initial setup, your tenancy only contains a root compartment. A tenancy administrator needs to perform setup tasks and establish an organization plan. The plan should include the compartment hierarchy for organizing your resources and the definitions of the user groups that need access to the resources. These two things impact how you write policies to manage access, and therefore should be considered together.

Understanding Compartments

Think carefully about how you want to use compartments to organize and isolate your cloud resources. Compartments are fundamental to that process. Most resources can be moved between compartments. However, it's important to think through your compartment design for your organization up front, before implementing anything.

When planning your compartment structure, keep the following things in mind:

You can create a hierarchy up to six compartments deep under the tenancy or root compartment.
Compartments are logical, not physical. Related resource components can be placed in different compartments. For example, your cloud network subnets with access to an internet gateway can be secured in a separate compartment from other subnets in the same cloud network.
Compartments behave like a filter for viewing resources. When you select a compartment, the Compute Web UI only shows you resources that are in that compartment. To view resources in another compartment, you must first select that compartment.

This experience is different when viewing users, groups, and federation providers. Those reside in the tenancy itself, not in an individual compartment. A policy can be attached to either the tenancy or a compartment. Where it is attached controls who has access to modify or delete it.
The Compute Web UI only displays the compartments and resources that you have permission to access. Only an administrator can view all compartments and work with all resources.
At the time you create a resource (for example, instance, block storage volume, VCN, subnet), you must decide in which compartment to put it.

Considerations for Granting Resource Access

Another primary consideration when planning the setup of your tenancy is who should have access to which resources. Defining how different groups of users need to access the resources helps you plan how to organize your resources most efficiently, making it easier to write and maintain your access policies.

For example, you might have users who need to:

View the Compute Web UI, but not be allowed to edit or create resources
Create and update specific resources across several compartments; for example: network administrators who need to manage your cloud networks and subnets
Launch and manage instances and block volumes, but not have access to your cloud network
Have full permissions on all resources, but only in a specific compartment
Manage other users' permissions and credentials

For information on accessing resources across tenancies, see Cross-Tenancy Policies.

Examples of Compartment Organization

This section describes examples of how compartments can be structured to align with your resource management goals.

All Resources in the Root Compartment

If your organization is small, or if you are still in the proof-of-concept stage, you might consider placing all of your resources in the root compartment or the tenancy. This approach makes it easy for you to quickly view and manage all your resources. You can still write policies and create groups to restrict permissions on specific resources to only the users who need access.

High-level tasks to set up the single compartment approach:

Create a sandbox compartment. Even though your plan is to maintain your resources in the root compartment, Oracle recommends setting up a sandbox compartment so that you can give users a dedicated space to try out features. In the sandbox compartment you can grant users permissions to create and manage resources, while maintaining stricter permissions on the resources in your tenancy (root) compartment.
Create groups and policies.
Add users.

Separately Managed Project Compartments

Consider this approach if your organization has multiple departments that you want to manage separately, or if several distinct projects exist that would be easier to manage separately.

In this approach, you can add a dedicated administrators group for each project compartment who can set the access policies for just that project. Users and groups still must be added at the tenancy level. You can give one group control over all their resources, while not allowing them administrator rights to the root compartment or any other projects. This way, you enable different groups to set up their own "sub-clouds" for their own resources and manage them independently.

High-level tasks to set up the multi-project approach:

Create a sandbox compartment. Oracle recommends setting up a sandbox compartment so that you can give users a dedicated space to try out features. In the sandbox compartment you can grant users permissions to create and manage resources, while maintaining stricter permissions on the resources in your tenancy and other compartments.
Create a compartment for each project. For example: ProjectA, ProjectB.
Create an administrators group for each project. For example: ProjectA_Admins.

Create a policy for each administrators group. For example:

Allow group ProjectA_Admins to manage all-resources in compartment ProjectA

Add users.
Let the administrators for ProjectA and ProjectB create subcompartments within their designated compartment to manage resources.
Let the administrators for ProjectA and ProjectB create the policies to manage the access to their compartments.

Working with Compartments

This section describes the basics of compartment management.

Creating Compartments

When creating a compartment, you must provide a name that is unique within the tenancy. It can be up to 100 characters long, and include letters, numbers, periods, hyphens, and underscores. You must also provide a description for the compartment, which must be 1-400 characters long and is non-unique and changeable. The new compartment is automatically assigned a unique identifier called an Oracle Cloud ID (OCID).

You can create subcompartments within compartments, to create hierarchies that are up to six levels deep.

Compartment Access Control

After creating a compartment, you need to write at least one policy for it, otherwise it is only accessible to administrators and users with permissions set at the tenancy level. When creating a compartment inside another compartment, the subcompartment inherits access permissions from compartments higher up its hierarchy.

When you create an access policy, you need to specify which compartment to attach it to. This controls who can later modify or delete the policy. Depending on your compartment hierarchy design, you might attach it to the tenancy, a parent, or to the specific compartment itself.

For information on accessing resources across tenancies, see Cross-Tenancy Policies.

Adding Resources to Compartments

When you start working with cloud resources in the Compute Web UI, you must choose from a list which compartment to work in. That list is filtered to show only the compartments in the tenancy that you have permission to access.

To place a new resource in a compartment, you simply specify that compartment when creating the resource. The compartment is one of the required parameters to create a resource. When working in the Compute Web UI, make sure you are first viewing the compartment where you want to create the resource.

Keep in mind that most IAM resources reside in the tenancy. This is always the case for users and groups, but compartments and policies are also often attached to the tenancy. Tenancy-level resources cannot be created or managed from a specific compartment.

Moving Resources Between Compartments

Most resources can be moved after they are created.

Some resources have attached resource dependencies. When the parent resource is moved to another compartment, the attached dependencies do not all behave in the same way. Some are moved immediately with their parent resources, and some are moved asynchronously, meaning they are not visible in the new compartment until the move is complete. For other resources, the attached resource dependencies are not automatically moved to the new compartment. You can move these attached resources independently.

After you move a resource to a new compartment, the policies that govern the new compartment apply immediately and affect access to the resource. See the service documentation for individual resources to familiarize yourself with the behavior of each resource and its attachments.

Deleting Compartments

To delete a compartment, it must be empty of all resources. Before you initiate deleting a compartment, be sure that all its resources have been moved, deleted, or terminated, including any policies attached to the compartment.

The delete action is asynchronous and initiates a work request, which typically takes several minutes to complete. While a compartment is in the deleting state it is not displayed in the compartment picker. If the work request fails, the compartment is not deleted and it returns to the active state. You can track the progress of a work request during the operation, or check afterwards whether it completed successfully or if errors occurred.

After a compartment is deleted, its state is updated to deleted and a random string of characters is appended to its name. For example, CompartmentA might become CompartmentA.qR5hP2BD. Renaming the compartment allows you to reuse the original name for a different compartment. Deleted compartments are listed in the Compartments page for 365 days, but are removed from the compartment picker. If any policy statements reference the deleted compartment, these statements are updated to reflect the new name.

If the work request indicates that the compartment failed to delete, verify that you have removed all the resources. Verify that there are no policies in the compartment. If you cannot locate any resources in the compartment, check with your administrator; you might not have permission to view all resources.

Moving a Compartment to a Different Parent Compartment

To move a compartment, you must belong to a group that has manage all-resources permissions on the lowest shared parent compartment of the current compartment and the destination compartment.

You can move a compartment to a different parent compartment within the same tenancy. When you move a compartment, all its contents, meaning its subcompartments and resources, are moved with it. This section also describes the implications of moving a compartment. Ensure that you are aware of these before you move a compartment.

When moving a compartment, these restrictions apply:

You cannot move a compartment to a destination compartment with the same name as the compartment being moved.
Two compartments within the same parent cannot have the same name. Therefore you cannot move a compartment to a destination compartment where a compartment with the same name already exists.

Policy Implications

After you move a compartment to a new parent compartment, the access policies of the new parent take effect and the policies of the previous parent no longer apply. Before you move a compartment, ensure that:

You are aware of the policies that govern access to the compartment in its current position.
You are aware of the polices in the new parent compartment that will take effect when you move the compartment.

Groups with access to resources in the current compartment lose their permissions when the compartment is moved; groups with permissions in the destination compartment gain access. Ensure that you are aware not only of what groups lose permissions when you move a compartment, but also what groups will gain permissions. If necessary, adjust the policy statements to avoid certain users inadvertently losing access.

Tagging Implications

Tags are not automatically updated after a compartment has been moved. If you have implemented a tagging strategy based on compartment, you must update the tags on the resources after moving the compartment.

For example, assume that CompartmentA has a child compartment named CompartmentB. CompartmentA is set up with tag defaults so that every resource in CompartmentA is tagged with TagA. Therefore CompartmentB and all its resources are tagged with this default tag, TagA. When you move CompartmentB to CompartmentC, it will still have the default tags from CompartmentA. If you have set up default tags for CompartmentC, you need to add them to the resources in the moved compartment.

How Policies Work

A policy is a document that specifies who can access which cloud resources in your tenancy, and how. A policy simply allows a group to work in certain ways with specific types of resources in a particular compartment. If you are not familiar with users, groups, or compartments, refer to the respective sections in the chapter Identity and Access Management Overview.

Policy Basics

To govern control of your resources, you need at least one policy. Each policy consists of one or more policy statements that follow this basic syntax:

Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name>

Policy statements begin with the word Allow. Policies only allow access; they cannot deny it. Instead, all access is implicitly denied, meaning users can only do what they have been granted permission for. A tenancy administrator defines the groups and compartments; the available resource types are determined by Oracle. The use and meaning of verbs in policy statements is described in Policy Syntax.

If you want a policy to apply to the tenancy and not a compartment inside the tenancy, change the end of the policy statement as follows:

Allow group <group_name> to <verb> <resource-type> in tenancy

A basic feature of policies is the concept of inheritance: compartments inherit any policies from their parent compartment. If a group has a particular level of access to certain resource types in a compartment, then those same permissions apply in all subcompartments of the compartment where this policy is applied. The simplest example is the Administrators group in the tenancy: the built-in policy allows the administrators to manage all the resources in the tenancy root compartment. Because of policy inheritance, the administrators have full access to all operations and all resources in every compartment.

Resource Types

The resource types that you can use in policies are either individual or family types. The family resource types make policy writing easier, as they include multiple individual resource types that are often managed together. For example, the virtual-network-family type brings together a variety of types related to the management of VCNs: vcns, subnets, route-tables, security-lists, etc. If you need to write a more granular policy, use an individual resource type to give access to only those specific resources. Note that there are other ways to make policies more granular, such as the ability to specify conditions under which the access is granted.

With future service updates, it is possible that resource type definitions are changed or added. These are typically reflected automatically in the resource family type for that service, so your policies remain current.

Some operations require access to multiple resource types. For example, launching an instance requires the permission to create instances and to work with a cloud network. Or creating a volume backup requires access to both the volume and the volume backup. That means you have separate statements to give access to each resource type.

These individual statements do not have to be in the same policy. A user can gain the required access from being in different groups. For example, a user could be in one group that gives the required level of access to the volumes resource type, and in another group that gives the required access to the volume-backups resource type. The sum of the individual statements, regardless of their location in the overall set of policies, allows the user to create a volume backup.

Policy Attachment

Another basic feature of policies is the concept of attachment. When you create a policy you must attach it to a compartment; or to the tenancy, which is the root compartment. Where you attach it controls who can then modify it or delete it. If you attach a policy to the tenancy, it can only be modified by the Administrators group, and not by users with only access to a subcompartment.

If you instead attach the policy to a child compartment, then anyone with access to manage the policies in that compartment can change or delete it. In practical terms, you can give compartment administrators – a group with access to manage all resources in the compartment – access to manage their own compartment's policies, without giving them broader access to manage policies that reside in the tenancy.

To attach a policy to a compartment, you must be in that compartment when you create the policy. As part of a policy statement you specify the compartment it applies to, so if you try to attach the policy to a different compartment you get an error. Policy attachment occurs at the time of creation, which means a policy can be attached to one compartment only.

Policy Syntax

The overall syntax of a policy statement is as follows:

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

Additional spaces or line breaks in the statement have no effect.

Subject

Specify a group by name or OCID. You can specify multiple groups separated by commas. To cover all users in the tenancy, specify any-user.

These examples show how you can specify the subject in a policy statement.

To specify a single group by name:

Allow group A-admins to manage all-resources in compartment Project-A

To specify multiple groups by name (a space after the comma is optional):
```
Allow group A-admins, B-admins to manage all-resources in compartment Projects
```

To specify a single group by OCID (the OCID is shortened for brevity):

Allow group id ocid1.group...........<group1_unique_id>
to manage all-resources in compartment Project-A

To specify multiple groups by OCID (the OCIDs are shortened for brevity):

Allow 
group id ocid1.group...........<group1_unique_id>, 
group id ocid1.group...........<group2_unique_id>
to manage all-resources in compartment Projects

To specify any user in the tenancy:

Allow any-user to inspect users in tenancy

Verb

Specify a single verb.

Allow group A-admins to manage all resources in compartment Project-A

The policy syntax supports the following verbs, ordered by increasing permissions:

Verb	Type of Access	Target User
`inspect`	Ability to list resources, without access to any confidential information or user-specified metadata that may be part of that resource. Notes: The operation to list policies includes the contents of the policies themselves. The list operations for the Networking resource types return all the information, including the contents of security lists and route tables.	Third-party auditors
`read`	Includes `inspect` plus the ability to get user-specified metadata and the actual resource itself.	Internal auditors
`use`	Includes `read` plus the ability to work with existing resources. The actions vary by resource type. Includes the ability to update the resource, except for resource types where the "update" operation has the same effective impact as the "create" operation; for example `UpdatePolicy`, `UpdateSecurityList`, etc. In those cases the "update" ability is available only with the `manage` verb. In general, the verb `use` does not include the ability to create or delete that type of resource.	Day-to-day end users of resources
`manage`	Includes all permissions for the resource.	Administrators

The verb gives a certain general type of access. For example, inspect lets you list and get resources. You then join that type of access with a particular resource type in a policy. For example, allow group XYZ to inspect compartments in the tenancy. As a result, that group gains access to a specific set of permissions and API operations; for example ListCompartments, GetCompartment.

Resource Type

Specify a single resource-type, which can be:

An individual resource type; for example: vcns, subnets, instances, volumes, etc.
A family resource type; for example: virtual-network-family, instance-family, volume-family, etc.

A family resource type covers a variety of individual resource types that are typically used together.
all-resources: Covers all resources in the compartment or tenancy.

These examples show how you can specify the resource type in a policy statement.

To specify a single resource type:

Allow group HelpDesk to manage users in tenancy

To specify multiple resource types, use separate statements:

Allow group A-users to manage instance-family in compartment Project-A
Allow group A-users to manage volume-family in compartment Project-A

To specify all resources in the compartment or tenancy:

Allow group A-admins to manage all-resources in compartment Project-A

Here is an overview of the family resource types can be used in policy statements:

Family Resource Type	Description
`compute-management-family`	This aggregate resource covers the following individual resource types: `instance-configurations`, `instance-pools`, `cluster-networks`.
`instance-family`	This aggregate resource covers the following individual resource types: `app-catalog-listing`, `console-histories`, `instances`, `instance-console-connection`, `instance-images`, `volume-attachments`.
`volume-family`	This aggregate resource covers all individual resource types related to block volumes: `volumes`, `volume-attachments`, `volume-backups`, `boot-volume-backups`, `backup-policies`, `backup-policy-assignments`, `volume-groups`, `volume-group-backups`.
`virtual-network-family`	This aggregate resource covers all individual resource types related to the networking service. For example: VCNs, subnets, route tables, gateways, VNICs, network security groups, and so on.
`file-family`	This aggregate resource covers all individual resource types related to the file storage service: `file-systems`, `mount-targets`, `export-sets`.
`object-family`	This aggregate resource covers all individual resource types related to the object storage service: `objectstorage-namespaces`, `buckets`, `objects`.

Location

Specify a single compartment by name or OCID. Or simply specify tenancy to cover the entire tenancy. Remember that users, groups, and compartments reside in the tenancy. Policies can be attached to either the tenancy or a child compartment.

The location is required in the statement. If you want to attach a policy to a compartment, you must be in that compartment when you create the policy.

These examples show how you can specify the location in a policy statement.

To specify a compartment by name:

Allow group A-admins to manage all-resources in compartment Project-A

To specify a compartment by OCID:

Allow group A-admins to manage all-resources
in compartment id ocid1.compartment.oc1..aaaaaaaaexampleocid

To specify multiple compartments, use separate statements:

Allow group InstanceAdmins to manage instance-family in compartment Project-A
Allow group InstanceAdmins to manage instance-family in compartment Project-B

Allow group InstanceAdmins to manage instance-family
in compartment id ocid1.compartment.oc1..aaaaaaaayzexampleocid
Allow group InstanceAdmins to manage instance-family
in compartment id ocid1.compartment.oc1..abcabcabcexampledocid

Conditions

Specify one or more conditions. With multiple conditions, use any or all for a logical OR or AND, respectively.

These are the types of values you can use in conditions:

Value Type Examples

Value Type	Examples
String	Single quotation marks are required around the value. `'johnsmith@example.com'` `'ocid1.compartment.oc1..aaaaaaaaph...ctehnqg756a'`
Pattern	`/HR/` - matches strings that start with "HR" `/HR/` - matches strings that end with "HR" `/HR/` - matches strings that contain "HR"

String

Single quotation marks are required around the value.

'johnsmith@example.com'

'ocid1.compartment.oc1..aaaaaaaaph...ctehnqg756a'

Pattern

/HR*/ - matches strings that start with "HR"

/*HR/ - matches strings that end with "HR"

/*HR*/ - matches strings that contain "HR"

These examples show how you can specify conditions in a policy statement.

Note:

In the example statements, the condition to match group names makes it impossible for GroupAdmins to list all users and groups. The list operation does not involve specifying a group, which means there is no value to match the condition variable target.group.name. To resolve this, a statement including the inspect verb is added.

The following policy enables the GroupAdmins group to create, update, or delete any groups with names that start with "A-Users-":
```
Allow group GroupAdmins to manage groups in tenancy where target.group.name = /A-Users-*/
Allow group GroupAdmins to inspect groups in tenancy
```

The following policy enables the NetworkAdmins group to manage cloud networks in any compartment except the one specified:

Allow group NetworkAdmins to manage virtual-network-family in tenancy
where target.compartment.id != 'ocid1.compartment.oc1..aaaaaaaaexampleocid'

The following policy uses multiple conditions and lets GroupAdmins create, update, or delete any groups whose names start with "A-", except for the A-Admins group itself:
```
Allow group GroupAdmins to manage groups in tenancy
where all {target.group.name=/A-*/,target.group.name!='A-Admins'}
Allow group GroupAdmins to inspect groups in tenancy
```

Common Policies

This section includes some common policies you might want to use in your organization. These policies use example group and compartment names. Make sure to replace them with your own names.

Let the help desk manage users

Type of access: Ability to create, update, and delete users and their credentials. It does not include the ability to put users in groups.

Where to create the policy: In the tenancy, because users reside in the tenancy.

Allow group HelpDesk to manage users in tenancy

Let auditors inspect your resources

Type of access: Ability to list the resources in all compartments. Be aware that:

The operation to list IAM policies includes the contents of the policies themselves
The list operations for Networking resource types return all the information (for example, the contents of security lists and route tables)
The operation to list instances requires the read verb instead of inspect, and the contents include the user-provided metadata

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, auditors can then inspect both the tenancy and all compartments beneath it. Or you could choose to give auditors access to only specific compartments if they don't need access to the entire tenancy.

Allow group Auditors to inspect all-resources in tenancy
Allow group Auditors to read instances in tenancy

Let network admins manage a cloud network

Type of access: Ability to manage all components in Networking. This includes cloud networks, subnets, gateways, security lists, route tables, and so on.

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, NetworkAdmins can then manage a cloud network in any compartment. To reduce the scope of access to a particular compartment, specify that compartment instead of the tenancy.

Allow group NetworkAdmins to manage virtual-network-family in tenancy

Let users launch compute instances

Type of access: Ability to do everything with instances launched into the cloud network and subnets in compartment XYZ, and attach/detach any existing volumes that already exist in compartment ABC. The first statement also lets the group create and manage instance images in compartment ABC.

Where to create the policy: The easiest approach is to put this policy in the tenancy. If you want the admins of the individual compartments (ABC and XYZ) to have control over the individual policy statements for their compartments, these policy statements need to be split across two policies and attached to the compartment they apply to.

Allow group InstanceLaunchers to manage instance-family in compartment ABC
Allow group InstanceLaunchers to use volume-family in compartment ABC
Allow group InstanceLaunchers to use virtual-network-family in compartment XYZ

Let users manage compute instance configurations, instance pools, and cluster networks

Type of access: Ability to do all things with instance configurations, instance pools, and cluster networks in all compartments.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the instance configurations, instance pools, and cluster networks in a particular compartment, specify that compartment instead of the tenancy.

Allow group InstancePoolAdmins to manage compute-management-family in tenancy

If a group needs to create instance configurations using existing instances as a template, and uses the API or CLI to do this, add the following statements to the policy:

Allow group InstancePoolAdmins to read instance-family in tenancy
Allow group InstancePoolAdmins to inspect volumes in tenancy

If a particular group needs to start, stop, or reset the instances in existing instance pools, but not create or delete instance pools, use this statement:

Allow group InstancePoolUsers to use instance-pools in tenancy

If resources used by the instance pool contain default tags, add the following statement to the policy to give the group permission to the tag namespace "oracle-tags":

Allow group InstancePoolUsers to use tag-namespaces in tenancy where target.tag-namespace.name = 'oracle-tags'

Let volume admins manage block volumes, backups, and volume groups

Type of access: Ability to do all things with block storage volumes, volume backups, and volume groups in all compartments with the exception of copying volume backups across regions. This makes sense if you want to have a single set of volume admins manage all the volumes, volume backups, and volume groups in all the compartments. The second statement is required in order to attach/detach the volumes from instances.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the volumes/backups and instances in a particular compartment, specify that compartment instead of the tenancy.

Allow group VolumeAdmins to manage volume-family in tenancy
Allow group VolumeAdmins to use instance-family in tenancy

Let volume backup admins manage only backups

Type of access: Ability to do all things with volume backups, but not create and manage volumes themselves. This makes sense if you want to have a single set of volume backup admins manage all the volume backups in all the compartments. The first statement gives the required access to the volume that is being backed up; the second statement enables creation of the backup and the ability to delete backups. The third statement enables the creation and management of user defined backup policies; the fourth statement enables assignment and removal of assignment of backup policies.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the volumes and backups in a particular compartment, specify that compartment instead of the tenancy.

Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancy

If the group uses the Compute Web UI, extend the policy as shown below for a better user experience.

Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy
Allow group VolumeBackupAdmins to inspect instances in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancy

The last two statements are not strictly required. They enable the display of all information about a particular volume and available backup policies.

Let boot volume backup admins manage only backups

Type of access: Ability to do all things with boot volume backups, but not create and manage boot volumes themselves. This makes sense if you want to have a single set of boot volume backup admins manage all the boot volume backups in all the compartments. The first statement gives the required access to the boot volume that is being backed up; the second statement enables creation of the backup and the ability to delete backups. The third statement enables the creation and management of user defined backup policies; the fourth statement enables assignment and removal of assignment of backup policies.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the boot volumes and backups in a particular compartment, specify that compartment instead of the tenancy.

Allow group BootVolumeBackupAdmins to use volumes in tenancy
Allow group BootVolumeBackupAdmins to manage boot-volume-backups in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policies in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policy-assignments in tenancy

If the group uses the Compute Web UI, extend the policy as shown below for a better user experience.

Allow group BootVolumeBackupAdmins to use volumes in tenancy
Allow group BootVolumeBackupAdmins to manage boot-volume-backups in tenancy
Allow group BootVolumeBackupAdmins to inspect instances in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policies in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policy-assignments in tenancy

The last two statements are not strictly required. They enable the display of all information about a particular volume and available backup policies.

Let users create a volume group

Type of access: Ability to create a volume group from a set of volumes.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the volumes and volume groups in a particular compartment, specify that compartment instead of the tenancy.

Allow group VolumeGroupCreators to inspect volumes in tenancy
Allow group VolumeGroupCreators to manage volume-groups in tenancy

Let users clone a volume group

Type of access: Ability to clone a volume group from an existing volume group.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the volumes and volume groups in a particular compartment, specify that compartment instead of the tenancy.

Allow group VolumeGroupCloners to inspect volumes in tenancy
Allow group VolumeGroupCloners to manage volume-groups in tenancy
Allow group VolumeGroupCloners to manage volumes in tenancy

Let users create a volume group backup

Type of access: Ability to create a volume group backup.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the volumes/backups and volume groups/volume group backups in a particular compartment, specify that compartment instead of the tenancy.

Allow group VolumeGroupBackupAdmins to inspect volume-groups in tenancy
Allow group VolumeGroupBackupAdmins to manage volumes in tenancy
Allow group VolumeGroupBackupAdmins to manage volume-group-backups in tenancy
Allow group VolumeGroupBackupAdmins to manage volume-backups in tenancy

Let users restore a volume group backup

Type of access: Ability to create a volume group by restoring a volume group backup.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the volumes/backups and volume groups/volume group backups in a particular compartment, specify that compartment instead of the tenancy.

Allow group VolumeGroupBackupAdmins to inspect volume-group-backups in tenancy
Allow group VolumeGroupBackupAdmins to read volume-backups in tenancy
Allow group VolumeGroupBackupAdmins to manage volume-groups in tenancy
Allow group VolumeGroupBackupAdmins to manage volumes in tenancy

Let users create, manage, and delete file systems

Type of access: Ability to create, manage, or delete a file system. Administrative functions for a file system include the ability to rename or delete it or disconnect from it.

Where to create the policy: In the tenancy, so that the ability to create, manage, or delete a file system is easily granted to all compartments by way of policy inheritance. To reduce the scope of these administrative functions to file systems in a particular compartment, specify that compartment instead of the tenancy.

Allow group StorageAdmins to manage file-family in tenancy

Let users create file systems

Type of access: Ability to create a file system.

Where to create the policy: In the tenancy, so that the ability to create a file system is easily granted to all compartments by way of policy inheritance. To reduce the scope of these administrative functions to file systems in a particular compartment, specify that compartment instead of the tenancy.

Allow group Managers to manage file-systems in tenancy
Allow group Managers to read mount-targets in tenancy

The second statement is required when users create a file system through the Compute Web UI. It enables the UI to display a list of mount targets that the new file system can be associated with.

Let object storage admins manage buckets and objects

Type of access: Ability to do all things with Object Storage buckets and objects in all compartments.

Where to create the policy: In the tenancy, so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the buckets and objects in a particular compartment, specify that compartment instead of the tenancy.

Allow group ObjectAdmins to manage buckets in tenancy
Allow group ObjectAdmins to manage objects in tenancy

Let users write objects to object storage buckets

Type of access: Ability to write objects to any object storage bucket in compartment ABC. Consider a situation where a client needs to regularly write log files to a bucket. This includes the ability to list the buckets in the compartment, list the objects in a bucket, and create a new object in a bucket. Although the second statement gives broad access with the manage verb, that access is then scoped down to only the OBJECT_INSPECT and OBJECT_CREATE permissions with the condition at the end of the statement.

Where to create the policy: The easiest approach is to put this policy in the tenancy. If you want the admins of compartment ABC to have control over the policy, it needs to be attached to that compartment.

Allow group ObjectWriters to read buckets in compartment ABC
Allow group ObjectWriters to manage objects in compartment ABC where any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}

To limit access to a specific bucket in a particular compartment, add the condition where target.bucket.name='<bucket_name>'. The following policy allows the user to list all the buckets in a particular compartment, but they can only list the objects in and upload objects to BucketA:

Allow group ObjectWriters to read buckets in compartment ABC
Allow group ObjectWriters to manage objects in compartment ABC 
  where all {target.bucket.name='BucketA', any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}

Let users download objects from object storage buckets

Type of access: Ability to download objects from any Object Storage bucket in compartment ABC. This consists of the ability to list the buckets in the compartment, list the objects in a bucket, and read existing objects in a bucket.

Allow group ObjectReaders to read buckets in compartment ABC
Allow group ObjectReaders to read objects in compartment ABC

To limit access to a specific bucket in a particular compartment, add the condition where target.bucket.name='<bucket_name>'. The following policy allows the user to list all buckets in a particular compartment, but they can only read the objects in and download from BucketA:

Allow group ObjectReaders to read buckets in compartment ABC
Allow group ObjectReaders to read objects in compartment ABC where target.bucket.name='BucketA'

Let users manage their own credentials

No policy is required to let users manage their own credentials. All users have the ability to change and reset their own passwords and manage their own API keys.

Let a compartment admin manage the compartment

Type of access: Ability to manage all aspects of a particular compartment. For example, a group called A-Admins could manage all aspects of a compartment called Project-A, including writing additional policies that affect the compartment.

Where to create the policy: In the tenancy.

Allow group A-Admins to manage all-resources in compartment Project-A

Advanced Policy Features

This section describes policy language features that let you grant more granular access.

Conditions

As part of a policy statement, you can specify one or more conditions that must be met in order for access to be granted. Each condition consists of one or more predefined variables that you specify values for in the policy statement. When someone requests access to the resource type in question, and the condition in the policy is met, it evaluates to true and the request is allowed.

There are two types of variables: those that are relevant to the request itself, and those relevant to the resource being acted upon in the request, also known as the target. The name of the variable is prefixed accordingly with either request or target followed by a period. For example, the request variable called request.operation represents the API operation being requested. This variable lets you write a broad policy statement, but add a condition based on the specific API operation.

Caution:

Condition matching is case insensitive. This is important to remember when writing conditions for resource types that allow case-sensitive naming. For example, the Object Storage service allows you to create both a bucket named "BucketA" and a bucket named "bucketA" in the same compartment. If you write a condition that specifies "BucketA", it will also apply to "bucketA", because the condition matching is case insensitive.

Non-Applicable Variables

As a general rule, if a variable is not applicable to the incoming request, the condition evaluates to false and the request is declined. This means that a request normally allowed by the combination of verb and resource type in a policy statement, is declined because it does not specify a value for the condition variable. If you want to grant the access associated with the policy statement without the condition, you need to include an additional statement.

For example, the policy statements below allow someone to add and remove users from any group, as long as they are not members of the Administrators group.

Allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'
Allow group GroupAdmins to use groups in tenancy where target.group.name != 'Administrators'

If a user in GroupAdmins calls a general API operation such as ListUsers or UpdateUser, the request is declined even though the operations are covered by use users. This is because the list and update commands do not involve specifying a group, which means there is no value to match the target.group.name variable in the condition of the policy statement. The variable is not applicable to the incoming request, therefore the condition evaluates to false and the request is declined.

To allow the GroupAdmins to list users, you need to add another policy statement, but without the condition. In this example, the verb inspect is required to allow the list command.

Allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'
Allow group GroupAdmins to use groups in tenancy where target.group.name != 'Administrators'
Allow group GroupAdmins to inspect users in tenancy

This general concept also applies to groups, and any other resource type with target variables.

Tag-Based Access Control

Using conditions and a set of tag variables, you can write policy to scope access based on the tags that have been applied to a resource. More specifically, access can be controlled based on the value of a tag that exists on the group to which the requesting user belongs. Tag-based access control provides additional flexibility to your policies by allowing you to define access that spans compartments, groups, and resources.

For details about how to write policies to scope access by tags, refer to the section "Tag-Based Access Control" in the chapter Tagging Overview.

Permissions

Permissions are the atomic units of authorization that control a user's ability to perform operations on resources. All the permissions are defined in the policy language. When you write a policy giving a group access to a particular verb and resource type, you are actually giving that group access to one or more predefined permissions. The purpose of verbs is to simplify the process of granting multiple related permissions that cover a broad set of access or a particular operational scenario.

Relation to Verbs

To understand the relationship between permissions and verbs, consider the following example. A policy statement that allows a group to inspect volumes actually provides access to a permission called VOLUME_INSPECT. Permissions are always written with all capital letters and underscores. In general, that permission enables the user to get information about block volumes.

As you go from inspect > read > use > manage, the level of access generally increases, and the permissions granted are cumulative, as shown in the table below. Note that in this case no additional permissions are granted going from inspect to read.

Inspect Volumes	Read Volumes	Use Volumes	Manage Volumes
VOLUME_INSPECT	VOLUME_INSPECT	VOLUME_INSPECT VOLUME_UPDATE VOLUME_WRITE	VOLUME_INSPECT VOLUME_UPDATE VOLUME_WRITE VOLUME_CREATE VOLUME_DELETE

Inspect Volumes

Read Volumes

Use Volumes

Manage Volumes

VOLUME_INSPECT

VOLUME_UPDATE

VOLUME_WRITE

VOLUME_INSPECT

VOLUME_UPDATE

VOLUME_WRITE

VOLUME_CREATE

VOLUME_DELETE

For detailed information about permissions covered by each verb for each given resource type, see the Policy Reference.

Relation to API Operations

Each API operation requires the caller to have access to one or more permissions. For example:

To use either ListVolumes or GetVolume, you must have access to a single permission: VOLUME_INSPECT.
To attach a volume to an instance, you must have access to multiple permissions, related to different resource types: volumes, volume-attachments and instances. Those permissions are, respectively: VOLUME_WRITE, VOLUME_ATTACHMENT_CREATE , and INSTANCE_ATTACH_VOLUME.

The Policy Reference lists which permissions are required for each API operation.

Understanding a User's Access

The policy language is designed to let you write simple statements involving only verbs and resource types, without having to state the desired permissions in the statement. However, there may be situations where a security team member or auditor wants to understand the specific permissions a particular user has. The Policy Reference lists the permissions associated with each verb. You can look at the groups the user is in and the policies applicable to those groups, and from there compile a list of the permissions granted.

However, having a list of the permissions is not the complete picture. Conditions in a policy statement can scope a user's access beyond individual permissions. Also, each policy statement specifies a particular compartment and can have conditions that further scope the access to only certain resources in that compartment.

Scoping Access with Permissions or API Operations

In a policy statement, you can use conditions combined with permissions or API operations to reduce the scope of access granted by a particular verb. For example, you want group XYZ to be able to list, get, create, or update groups, but not delete them. To list, get, create, and update groups, you need a policy with manage groups as the verb and resource type, but this would include the permission to delete groups.

To restrict access to only the desired permissions, you could add a condition that explicitly states the permissions you want to allow:

Allow group XYZ to manage groups in tenancy 
where any {request.permission='GROUP_INSPECT',
           request.permission='GROUP_CREATE',
           request.permission='GROUP_UPDATE'}

An alternative would be a policy that allows all permissions except GROUP_DELETE:

Allow group XYZ to manage groups in tenancy where request.permission != 'GROUP_DELETE'

However, with this approach, any future new permissions would automatically be granted to group XYZ. Only GROUP_DELETE would be omitted.

Another alternative would be to write a condition based on the specific API operations:

Allow group XYZ to manage groups in tenancy 
where any {request.operation='ListGroups',  
           request.operation='GetGroup',
           request.operation='CreateGroup',
           request.operation='UpdateGroup'}

It can be beneficial to use permissions instead of API operations in conditions. In the future, if a new API operation is added that requires one of the permissions listed in the permissions-based policy above, that policy already controls the XYZ group's access to that new API operation.

A user's access to a permission can be scoped even further by also specifying a condition based on API operation. For example, you could give a user access to GROUP_INSPECT, but then only to ListGroups.

Allow group XYZ to manage groups in tenancy
where all {request.permission='GROUP_INSPECT',request.operation='ListGroups'}

Cross-Tenancy Policies

Before You Begin

You can write policies to allow tenancy access from other tenancies so you can share resources across tenancies. The administrators of both tenancies need to create special policy statements that explicitly state which resources can be accessed and shared. These special statements use the following special verbs:

Verb Use in a Policy Statement

Verb	Use in a Policy Statement
`endorse`	Describes what work a group in a source tenancy can perform in other tenancies. You write the `endorse` statement for the tenancy that contains the group of users who need to work with another tenancy's resources.
`admit`	Describes what work a group from other tenancies can perform in a destination tenancy. You write the `admit` statement for the tenancy that is granting permission to access its resources. The `admit` statement identifies the group of users from the source tenancy that requires resource access in the destination tenancy.
`define`	Assigns an alias for a source tenancy OCID, a source group OCID, and a destination tenancy OCID. You define a source tenancy alias and a source group alias for use in `admit` policy statements. You define a destination tenancy alias for use in `endorse` policy statements. You must include a `define` statement in the same policy entity as the `endorse` or `admit` statement.

endorse

Describes what work a group in a source tenancy can perform in other tenancies. You write the endorse statement for the tenancy that contains the group of users who need to work with another tenancy's resources.

admit

Describes what work a group from other tenancies can perform in a destination tenancy. You write the admit statement for the tenancy that is granting permission to access its resources. The admit statement identifies the group of users from the source tenancy that requires resource access in the destination tenancy.

define

Assigns an alias for a source tenancy OCID, a source group OCID, and a destination tenancy OCID.

You define a source tenancy alias and a source group alias for use in admit policy statements. You define a destination tenancy alias for use in endorse policy statements.

You must include a define statement in the same policy entity as the endorse or admit statement.

The endorse and admit statements work together. An endorse statement resides in the source tenancy while an admit statement resides in the destination tenancy. Without a corresponding statement that specifies access, a particular endorse or admit statement grants no access. Both tenancies must agree on access and have policies that allow for access.

In the source tenancy, you write define and endorse policy statements using the following syntax:

define tenancy destination-tenancy-alias as tenancy_ocid

endorse group group-name to verb resource in tenancy destination-tenancy-alias

In the destination tenancy, you write two define policy statemens and an admit policy statement using the following syntax:

define tenancy source-tenancy-alias as tenancy_ocid

define group source-group-alias as group_ocid

admit group source-group-alias of tenancy source-tenancy-alias to verb resource in compartment/tenancy

For more information and examples of common statements, see "Writing Policies to Access Resources Across Tenancies" in the Identity and Access Management in the Oracle Private Cloud Appliance User Guide.

Policy Reference

Use this section as a source of information to help you write policies for access control in your tenancy. The table provides reference information as follows:

It lists all resource types for which policy statements can be written.
For each resource type, it lists the API operations that can be allowed or denied through policy statements.
For each API operation, it lists the required permissions and the associated verb/resource combination to be used in policy statements.

Note:

For some API operations the table displays no permission or verb/resource combination. These empty cells indicate that either no explicit permission is required for the operation, or the operation is dependent on other API operations and the permissions associated with those.

The IAM service is only aware of permissions directly associated with an API operation; it is not aware of further permission dependencies or conditions defined by other services for their specific resources.

The table may contain resource types and API operations that are not yet supported by the services available in your tenancy. Those rows can be ignored.

Resource Type	API Operation	Required Permissions	Verb + Resource Combination
users	CreateUser	USER_CREATE	manage users
	CreateOrResetUIPassword	USER_UIPASS_SET	manage users
	GetUser	USER_INSPECT	inspect users
	ListUsers	USER_INSPECT	inspect users
	ListApiKeys	USER_READ	read users
	UpdateUser	USER_UPDATE	use users
	UpdateUserState	USER_UNBLOCK	manage users
	UploadApiKey	USER_APIKEY_ADD	manage users
	DeleteUser	USER_DELETE	manage users
	DeleteApiKey	USER_APIKEY_REMOVE	manage users
	AddUserToGroup	USER_UPDATE	use users
	RemoveUserFromGroup	USER_UPDATE	use users
	GetUserGroupMembership	USER_INSPECT	inspect users
	ListUserGroupMemberships	USER_INSPECT	inspect users
groups	CreateGroup	GROUP_CREATE	manage groups
	GetGroup	GROUP_INSPECT	inspect groups
	ListGroups	GROUP_INSPECT	inspect groups
	UpdateGroup	GROUP_UPDATE	use groups
	DeleteGroup	GROUP_DELETE	manage groups
	AddUserToGroup	GROUP_UPDATE	use groups
	RemoveUserFromGroup	GROUP_UPDATE	use groups
	GetUserGroupMembership	GROUP_INSPECT	inspect groups
	ListUserGroupMemberships	GROUP_INSPECT	inspect groups
	ListIdpGroupMappings	GROUP_INSPECT	inspect groups
	CreateIdpGroupMapping	GROUP_UPDATE	use groups
	GetIdpGroupMapping	GROUP_INSPECT	inspect groups
	UpdateIdpGroupMapping	GROUP_UPDATE	use groups
	DeleteIdpGroupMapping	GROUP_UPDATE	use groups
compartments	ListCompartments	COMPARTMENT_INSPECT	inspect compartments
	GetCompartment	COMPARTMENT_INSPECT	inspect compartments
	ListAvailabilityDomains	COMPARTMENT_INSPECT	inspect compartments
	ListFaultDomains	COMPARTMENT_INSPECT	inspect compartments
	UpdateCompartment	COMPARTMENT_UPDATE	use compartments
	CreateCompartment	COMPARTMENT_CREATE	manage compartments
	DeleteCompartment	COMPARTMENT_DELETE	manage compartments
	RecoverCompartment	COMPARTMENT_RECOVER	manage compartments
	MoveCompartment	MANAGE_ALL_RESOURCES	manage all-resources
policies	ListPolicies	POLICY_READ	inspect policies
	GetPolicy	POLICY_READ	inspect policies
	UpdatePolicy	POLICY_UPDATE	manage policies
	CreatePolicy	POLICY_CREATE	manage policies
	DeletePolicy	POLICY_DELETE	manage policies
tag-defaults	ListTagDefaults	TAG_DEFAULT_INSPECT	inspect tag-defaults
	GetTagDefault	TAG_DEFAULT_INSPECT	inspect tag-defaults
	AssembleEffectiveTagSet	TAG_DEFAULT_INSPECT	inspect tag-defaults
	CreateTagDefault	TAG_DEFAULT_CREATE	manage tag-defaults
	UpdateTagDefault	TAG_DEFAULT_UPDATE	manage tag-defaults
	DeleteTagDefault	TAG_DEFAULT_DELETE	manage tag-defaults
tag-namespaces	ListTagNamespaces	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	GetTagNamespace	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	ListTags	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	ListCostTrackingTags	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	GetTag	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	GetTaggingWorkRequest	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	ListTaggingWorkRequests	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	ListTaggingWorkRequestErrors	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	ListTaggingWorkRequestLog	TAG_NAMESPACE_INSPECT	inspect tag-namespaces
	CreateTag	TAG_NAMESPACE_USE	use tag-namespaces
	UpdateTag	TAG_NAMESPACE_USE	use tag-namespaces
	UpdateTagNamespace	TAG_NAMESPACE_UPDATE	manage tag-namespaces
	CreateTagNamespace	TAG_NAMESPACE_CREATE	manage tag-namespaces
	ChangeTagNamespaceCompartment	TAG_NAMESPACE_MOVE	manage tag-namespaces
	DeleteTagNamespace	TAG_NAMESPACE_DELETE	manage tag-namespaces
	DeleteTag	TAG_NAMESPACE_DELETE	manage tag-namespaces
tenancies	ListRegionSubscriptions	TENANCY_INSPECT	inspect tenancies
	GetTenancy	TENANCY_INSPECT	inspect tenancies
	ListRegions	TENANCY_INSPECT	inspect tenancies
	CreateRegionSubscription	TENANCY_UPDATE	use tenancies
identity-providers	ListIdentityProviders	IDENTITY_PROVIDER_INSPECT	inspect identity-providers
	GetIdentityProvider	IDENTITY_PROVIDER_INSPECT	inspect identity-providers
	UpdateIdentityProvider	IDENTITY_PROVIDER_UPDATE	manage identity-providers
	CreateIdentityProvider	IDENTITY_PROVIDER_CREATE	manage identity-providers
	DeleteIdentityProvider	IDENTITY_PROVIDER_DELETE	manage identity-providers
	ListIdpGroupMappings	IDENTITY_PROVIDER_INSPECT	inspect identity-providers
	CreateIdpGroupMapping	IDENTITY_PROVIDER_UPDATE	manage identity-providers
	GetIdpGroupMapping	IDENTITY_PROVIDER_INSPECT	inspect identity-providers
	UpdateIdpGroupMapping	IDENTITY_PROVIDER_UPDATE	manage identity-providers
	DeleteIdpGroupMapping	IDENTITY_PROVIDER_UPDATE	manage identity-providers
work-requests	ListWorkRequests	WORKREQUEST_INSPECT	inspect work-requests
	GetWorkRequest	WORKREQUEST_INSPECT	inspect work-requests
	ListWorkRequestErrors	WORKREQUEST_INSPECT	inspect work-requests
	ListWorkRequestLogs	WORKREQUEST_INSPECT	inspect work-requests
instances	ListInstances	INSTANCE_READ	read instances
	GetInstance	INSTANCE_READ	read instances
	UpdateInstance	INSTANCE_UPDATE	use instances
	InstanceAction	INSTANCE_POWER_ACTIONS	use instances
	AttachVolume	INSTANCE_ATTACH_VOLUME	use instances
	DetachVolume	INSTANCE_DETACH_VOLUME	use instances
	ChangeInstanceCompartment	INSTANCE_MOVE	manage instances
	LaunchInstance	INSTANCE_CREATE	manage instances
	TerminateInstance	INSTANCE_DELETE	manage instances
	AttachVnic	INSTANCE_ATTACH_SECONDARY_VNIC	manage instances
	DetachVnic	INSTANCE_DETACH_SECONDARY_VNIC	manage instances
	ListVnicAttachments	INSTANCE_INSPECT	inspect instances
	ListShapes	INSTANCE_INSPECT	inspect instances
	CreateImage	INSTANCE_CREATE_IMAGE	use instances
	ListInstanceConsoleConnections	INSTANCE_INSPECT	inspect instances
	ListInstanceConsoleConnections	INSTANCE_READ	read instances
	GetInstanceConsoleConnection	INSTANCE_READ	read instances
	CreateInstanceConsoleConnection	INSTANCE_READ	read instances
	ListVolumeAttachments	INSTANCE_INSPECT	inspect instances
	ListBootVolumeAttachments	INSTANCE_INSPECT	inspect instances
	GetVolumeAttachment	INSTANCE_INSPECT	inspect instances
	GetBootVolumeAttachment	INSTANCE_INSPECT	inspect instances
	CreateInstancePool	INSTANCE_CREATE	manage instances
	TerminateInstancePool	INSTANCE_DELETE	manage instances
	ListConsoleHistories	INSTANCE_INSPECT	inspect instances
	CreateInstanceConfiguration	INSTANCE_READ	read instances
console-histories	ListConsoleHistories	CONSOLE_HISTORY_INSPECT	inspect console-histories
	GetConsoleHistory	CONSOLE_HISTORY_INSPECT	inspect console-histories
	ShowConsoleHistoryData	CONSOLE_HISTORY_READ	read console-histories
	DeleteConsoleHistory	CONSOLE_HISTORY_DELETE	manage console-histories
	CaptureConsoleHistory	CONSOLE_HISTORY_CREATE	manage console-histories
instance-console-connection	ListInstanceConsoleConnections	INSTANCE_CONSOLE_CONNECTION_INSPECT	inspect instance-console-connection
	GetInstanceConsoleConnection	INSTANCE_CONSOLE_CONNECTION_READ	read instance-console-connection
	DeleteInstanceConsoleConnection	INSTANCE_CONSOLE_CONNECTION_DELETE	manage instance-console-connection
	CreateInstanceConsoleConnection	INSTANCE_CONSOLE_CONNECTION_CREATE	manage instance-console-connection
	UpdateInstanceConsoleConnection	INSTANCE_CONSOLE_CONNECTION_CREATE	manage instance-console-connection
	UpdateInstanceConsoleConnection	INSTANCE_CONSOLE_CONNECTION_DELETE	manage instance-console-connection
instance-images	ListImages	INSTANCE_IMAGE_READ	read instance-images
	GetImage	INSTANCE_IMAGE_READ	read instance-images
	LaunchInstance	INSTANCE_IMAGE_READ	read instance-images
	UpdateImage	INSTANCE_IMAGE_UPDATE	use instance-images
	DeleteImage	INSTANCE_IMAGE_DELETE	manage instance-images
	ChangeImageCompartment	INSTANCE_IMAGE_MOVE	manage instance-images
	CreateImage	INSTANCE_IMAGE_CREATE	manage instance-images
	CreateInstancePool	INSTANCE_IMAGE_READ	read instance-images
	ExportImage
app-catalog-listing	ListAppCatalogSubscriptions	APP_CATALOG_LISTING_INSPECT	inspect app-catalog-listing
	CreateAppCatalogSubscription	APP_CATALOG_LISTING_SUBSCRIBE	manage app-catalog-listing
	DeleteAppCatalogSubscription	APP_CATALOG_LISTING_SUBSCRIBE	manage app-catalog-listing
volume-attachments-partial	AttachVolume	VOLUME_ATTACHMENT_CREATE	manage volume-attachments-partial
volume-attachments-partial	DetachVolume	VOLUME_ATTACHMENT_DELETE	manage volume-attachments-partial
instance-configurations	ListInstanceConfigurations	INSTANCE_CONFIGURATION_INSPECT	inspect instance-configurations
	GetInstanceConfiguration	INSTANCE_CONFIGURATION_READ	read instance-configurations
	CreateInstanceConfiguration	INSTANCE_CONFIGURATION_CREATE	manage instance-configurations
	UpdateInstanceConfiguration	INSTANCE_CONFIGURATION_UPDATE	manage instance-configurations
	LaunchInstanceConfiguration	INSTANCE_CONFIGURATION_LAUNCH	manage instance-configurations
	DeleteInstanceConfiguration	INSTANCE_CONFIGURATION_DELETE	manage instance-configurations
	ChangeInstanceConfigurationCompartment	INSTANCE_CONFIGURATION_MOVE	manage instance-configurations
instance-pools	ListInstancePools	INSTANCE_POOL_INSPECT	inspect instance-pools
	GetInstancePool	INSTANCE_POOL_READ	read instance-pools
	ListInstancePoolInstances	INSTANCE_POOL_READ	read instance-pools
	ResetInstancePool	INSTANCE_POOL_POWER_ACTIONS	use instance-pools
	SoftresetInstancePool	INSTANCE_POOL_POWER_ACTIONS	use instance-pools
	StartInstancePool	INSTANCE_POOL_POWER_ACTIONS	use instance-pools
	StopInstancePool	INSTANCE_POOL_POWER_ACTIONS	use instance-pools
	UpdateInstancePool	INSTANCE_POOL_UPDATE	manage instance-pools
	ChangeInstancePoolCompartment	INSTANCE_POOL_MOVE	manage instance-pools
	CreateInstancePool	INSTANCE_POOL_CREATE	manage instance-pools
	TerminateInstancePool	INSTANCE_POOL_DELETE	manage instance-pools
auto-scaling-configurations	ListAutoScalingConfigurations	AUTO_SCALING_CONFIGURATION_INSPECT	inspect auto-scaling-configurations
	ListAutoScalingPolicies	AUTO_SCALING_CONFIGURATION_INSPECT	inspect auto-scaling-configurations
	GetAutoScalingConfiguration	AUTO_SCALING_CONFIGURATION_READ	read auto-scaling-configurations
	GetAutoScalingPolicy	AUTO_SCALING_CONFIGURATION_READ	read auto-scaling-configurations
	ChangeAutoScalingConfigurationCompartment	AUTO_SCALING_CONFIGURATION_MOVE	manage auto-scaling-configurations
	CreateAutoScalingConfiguration	AUTO_SCALING_CONFIGURATION_CREATE	manage auto-scaling-configurations
	UpdateAutoScalingConfiguration	AUTO_SCALING_CONFIGURATION_UPDATE	manage auto-scaling-configurations
	DeleteAutoScalingConfiguration	AUTO_SCALING_CONFIGURATION_DELETE	manage auto-scaling-configurations
	CreateAutoScalingPolicy	AUTO_SCALING_CONFIGURATION_CREATE	manage auto-scaling-configurations
	UpdateAutoScalingPolicy	AUTO_SCALING_CONFIGURATION_UPDATE	manage auto-scaling-configurations
	DeleteAutoScalingPolicy	AUTO_SCALING_CONFIGURATION_DELETE	manage auto-scaling-configurations
dedicated-vm-hosts	ListDedicatedVmHosts	DEDICATED_VM_HOST_INSPECT	inspect dedicated-vm-hosts
	GetDedicatedVmHost	DEDICATED_VM_HOST_READ	read dedicated-vm-hosts
	ListDedicatedVmHostInstances	DEDICATED_VM_HOST_READ	read dedicated-vm-hosts
	UpdateDedicatedVmHost	DEDICATED_VM_HOST_UPDATE	use dedicated-vm-hosts
	CreateDedicatedVmHost	DEDICATED_VM_HOST_CREATE	manage dedicated-vm-hosts
	DeleteDedicatedVmHost	DEDICATED_VM_HOST_DELETE	manage dedicated-vm-hosts
	ChangeDedicatedVmHostCompartment	DEDICATED_VM_HOST_MOVE	manage dedicated-vm-hosts
vcns	ListVcns	VCN_READ	inspect vcns
	GetVcn	VCN_READ	inspect vcns
	CreateVcn	VCN_CREATE	manage vcns
	UpdateVcn	VCN_UPDATE	manage vcns
	DeleteVcn	VCN_DELETE	manage vcns
	ChangeVcnCompartment	VCN_MOVE	manage vcns
	CreateDhcpOptions	VCN_ATTACH	manage vcns
	DeleteDhcpOptions	VCN_DETACH	manage vcns
	CreateInternetGateway	VCN_ATTACH	manage vcns
	DeleteInternetGateway	VCN_DETACH	manage vcns
	CreateLocalPeeringGateway	VCN_ATTACH	manage vcns
	DeleteLocalPeeringGateway	VCN_DETACH	manage vcns
	CreateNatGateway	VCN_READ	inspect vcns
	CreateNatGateway	VCN_ATTACH	manage vcns
	DeleteNatGateway	VCN_READ	inspect vcns
	DeleteNatGateway	VCN_DETACH	manage vcns
	CreateNetworkSecurityGroup	VCN_ATTACH	manage vcns
	DeleteNetworkSecurityGroup	VCN_DETACH	manage vcns
	DeleteSubnet	VCN_DETACH	manage vcns
	CreateSubnet	VCN_ATTACH	manage vcns
	CreateServiceGateway	VCN_READ	inspect vcns
	CreateServiceGateway	VCN_ATTACH	manage vcns
	DeleteServiceGateway	VCN_READ	inspect vcns
	DeleteServiceGateway	VCN_DETACH	manage vcns
	CreateRouteTable	VCN_ATTACH	manage vcns
	DeleteRouteTable	VCN_DETACH	manage vcns
	UpdateRouteTable	VCN_ATTACH	manage vcns
	UpdateRouteTable	VCN_DETACH	manage vcns
	CreateDrgAttachment	VCN_ATTACH	manage vcns
	DeleteDrgAttachment	VCN_DETACH	manage vcns
subnets	ListSubnets	SUBNET_READ	inspect subnets
	GetSubnet	SUBNET_READ	inspect subnets
	ChangeSubnetCompartment	SUBNET_MOVE	manage subnets
	CreateSubnet	SUBNET_CREATE	manage subnets
	DeleteSubnet	SUBNET_DELETE	manage subnets
	UpdateSubnet	SUBNET_UPDATE	manage subnets
	LaunchInstance	SUBNET_ATTACH	use subnets
	TerminateInstance	SUBNET_DETACH	use subnets
	AttachVnic	SUBNET_ATTACH	use subnets
	DetachVnic	SUBNET_DETACH	use subnets
	CreateInstancePool	SUBNET_ATTACH	use subnets
	TerminateInstancePool	SUBNET_DETACH	use subnets
	CreatePrivateIp	SUBNET_ATTACH	use subnets
	CreateMountTarget	SUBNET_ATTACH	use subnets
	DeleteMountTarget	SUBNET_DETACH	use subnets
route-tables	ListRouteTables	ROUTE_TABLE_READ	inspect route-tables
	GetRouteTable	ROUTE_TABLE_READ	inspect route-tables
	ChangeRouteTableCompartment	ROUTE_TABLE_MOVE	manage route-tables
	CreateRouteTable	ROUTE_TABLE_CREATE	manage route-tables
	DeleteRouteTable	ROUTE_TABLE_DELETE	manage route-tables
	UpdateRouteTable	ROUTE_TABLE_UPDATE	manage route-tables
	CreateDrgAttachment	ROUTE_TABLE_ATTACH	manage route-tables
	UpdateDrgAttachment	ROUTE_TABLE_ATTACH	manage route-tables
	CreateLocalPeeringGateway	ROUTE_TABLE_ATTACH	manage route-tables
	UpdateLocalPeeringGateway	ROUTE_TABLE_ATTACH	manage route-tables
	DeleteSubnet	ROUTE_TABLE_DETACH	manage route-tables
	CreateSubnet	ROUTE_TABLE_ATTACH	manage route-tables
	UpdateSubnet	ROUTE_TABLE_ATTACH	manage route-tables
	UpdateSubnet	ROUTE_TABLE_DETACH	manage route-tables
	CreateServiceGateway	ROUTE_TABLE_ATTACH	manage route-tables
	UpdateServiceGateway	ROUTE_TABLE_ATTACH	manage route-tables
network-security-groups	CreateNetworkSecurityGroup	NETWORK_SECURITY_GROUP_CREATE	manage network-security-groups
	GetNetworkSecurityGroup	NETWORK_SECURITY_GROUP_INSPECT	inspect network-security-groups
	ListNetworkSecurityGroups	NETWORK_SECURITY_GROUP_INSPECT	inspect network-security-groups
	UpdateNetworkSecurityGroup	NETWORK_SECURITY_GROUP_UPDATE	manage network-security-groups
	DeleteNetworkSecurityGroup	NETWORK_SECURITY_GROUP_DELETE	manage network-security-groups
	ListNetworkSecurityGroupVnics	NETWORK_SECURITY_GROUP_LIST_MEMBERS	use network-security-groups
	ChangeNetworkSecurityGroupCompartment	NETWORK_SECURITY_GROUP_MOVE	manage network-security-groups
	ListNetworkSecurityGroupSecurityRules	NETWORK_SECURITY_GROUP_LIST_SECURITY_RULES	use network-security-groups
	AddNetworkSecurityGroupSecurityRules	NETWORK_SECURITY_GROUP_UPDATE_SECURITY_RULES	manage network-security-groups
	UpdateNetworkSecurityGroupSecurityRules	NETWORK_SECURITY_GROUP_UPDATE_SECURITY_RULES	manage network-security-groups
	RemoveNetworkSecurityGroupSecurityRules	NETWORK_SECURITY_GROUP_UPDATE_SECURITY_RULES	manage network-security-groups
	LaunchInstance	NETWORK_SECURITY_GROUP_UPDATE_MEMBERS	use network-security-groups
	AttachVnic	NETWORK_SECURITY_GROUP_UPDATE_MEMBERS	use network-security-groups
	UpdateVnic	NETWORK_SECURITY_GROUP_UPDATE_MEMBERS	use network-security-groups
security-lists	ListSecurityLists	SECURITY_LIST_READ	inspect security-lists
	GetSecurityList	SECURITY_LIST_READ	inspect security-lists
	UpdateSecurityList	SECURITY_LIST_UPDATE	manage security-lists
	ChangeSecurityListCompartment	SECURITY_LIST_MOVE	manage security-lists
	CreateSecurityList	SECURITY_LIST_CREATE	manage security-lists
	DeleteSecurityList	SECURITY_LIST_DELETE	manage security-lists
	DeleteSubnet	SECURITY_LIST_DETACH	manage security-lists
	CreateSubnet	SECURITY_LIST_ATTACH	manage security-lists
	UpdateSubnet	SECURITY_LIST_ATTACH	manage security-lists
	UpdateSubnet	SECURITY_LIST_DETACH	manage security-lists
dhcp-options	CreateDhcpOptions	DHCP_CREATE	manage dhcp-options
	GetDhcpOptions	DHCP_READ	inspect dhcp-options
	ListDhcpOptions	DHCP_READ	inspect dhcp-options
	UpdateDhcpOptions	DHCP_UPDATE	manage dhcp-options
	DeleteDhcpOptions	DHCP_DELETE	manage dhcp-options
	ChangeDhcpOptionsCompartment	DHCP_MOVE	manage dhcp-options
	DeleteSubnet	DHCP_DETACH	manage dhcp-options
	CreateSubnet	DHCP_ATTACH	manage dhcp-options
	UpdateSubnet	DHCP_ATTACH	manage dhcp-options
	UpdateSubnet	DHCP_DETACH	manage dhcp-options
private-ips	GetPrivateIp	PRIVATE_IP_READ	inspect private-ips
	ListPrivateIps	PRIVATE_IP_READ	inspect private-ips
	ListPublicIps	PRIVATE_IP_READ	inspect private-ips
	GetPublicIp	PRIVATE_IP_READ	inspect private-ips
	GetPublicIpByPrivateIpId	PRIVATE_IP_READ	inspect private-ips
	UpdatePrivateIp	PRIVATE_IP_UPDATE	use private-ips
	CreatePrivateIp	PRIVATE_IP_CREATE	use private-ips
	CreatePrivateIp	PRIVATE_IP_ASSIGN	use private-ips
	DeletePrivateIp	PRIVATE_IP_DELETE	use private-ips
	DeletePrivateIp	PRIVATE_IP_UNASSIGN	use private-ips
	CreateRouteTable	PRIVATE_IP_ROUTE_TABLE_ATTACH	manage private-ips
	DeleteRouteTable	PRIVATE_IP_ROUTE_TABLE_DETACH	manage private-ips
	UpdateRouteTable	PRIVATE_IP_ROUTE_TABLE_ATTACH	manage private-ips
	UpdateRouteTable	PRIVATE_IP_ROUTE_TABLE_DETACH	manage private-ips
	CreateMountTarget	PRIVATE_IP_CREATE	use private-ips
	CreateMountTarget	PRIVATE_IP_ASSIGN	use private-ips
	DeleteMountTarget	PRIVATE_IP_DELETE	use private-ips
	DeleteMountTarget	PRIVATE_IP_UNASSIGN	use private-ips
public-ips	GetPublicIp	PUBLIC_IP_READ	read public-ips
	ListPublicIps	PUBLIC_IP_READ	read public-ips
	GetPublicIpByPrivateIpId	PUBLIC_IP_READ	read public-ips
	GetPublicIpByIpAddress	PUBLIC_IP_READ	read public-ips
	UpdatePublicIp	PUBLIC_IP_UPDATE	manage public-ips
	CreatePublicIp	PUBLIC_IP_CREATE	manage public-ips
	DeletePublicIp	PUBLIC_IP_DELETE	manage public-ips
ipv6s	GetIpv6	IPV6_READ	read ipv6s
	ListIpv6s	IPV6_READ	read ipv6s
	UpdateIpv6	IPV6_UPDATE	manage ipv6s
	CreateIpv6	IPV6_CREATE	manage ipv6s
	DeleteIpv6	IPV6_DELETE	manage ipv6s
internet-gateways	ListInternetGateways	INTERNET_GATEWAY_READ	inspect internet-gateways
	GetInternetGateway	INTERNET_GATEWAY_READ	inspect internet-gateways
	UpdateInternetGateway	INTERNET_GATEWAY_UPDATE	manage internet-gateways
	ChangeInternetGatewayCompartment	INTERNET_GATEWAY_MOVE	manage internet-gateways
	CreateInternetGateway	INTERNET_GATEWAY_CREATE	manage internet-gateways
	DeleteInternetGateway	INTERNET_GATEWAY_DELETE	manage internet-gateways
	CreateRouteTable	INTERNET_GATEWAY_ATTACH	manage internet-gateways
	DeleteRouteTable	INTERNET_GATEWAY_DETACH	manage internet-gateways
	UpdateRouteTable	INTERNET_GATEWAY_ATTACH	manage internet-gateways
	UpdateRouteTable	INTERNET_GATEWAY_DETACH	manage internet-gateways
nat-gateways	ListNatGateways	NAT_GATEWAY_READ	read nat-gateways
	GetNatGateway	NAT_GATEWAY_READ	read nat-gateways
	UpdateNatGateway	NAT_GATEWAY_UPDATE	manage nat-gateways
	ChangeNatGatewayCompartment	NAT_GATEWAY_MOVE	manage nat-gateways
	CreateNatGateway	NAT_GATEWAY_CREATE	manage nat-gateways
	DeleteNatGateway	NAT_GATEWAY_DELETE	manage nat-gateways
	CreateRouteTable	NAT_GATEWAY_ATTACH	use nat-gateways
	DeleteRouteTable	NAT_GATEWAY_DETACH	use nat-gateways
	UpdateRouteTable	NAT_GATEWAY_ATTACH	use nat-gateways
	UpdateRouteTable	NAT_GATEWAY_DETACH	use nat-gateways
service-gateways	ListServiceGateways	SERVICE_GATEWAY_READ	inspect service-gateways
	GetServiceGateway	SERVICE_GATEWAY_READ	inspect service-gateways
	ChangeServiceGatewayCompartment	SERVICE_GATEWAY_MOVE	manage service-gateways
	AttachServiceId	SERVICE_GATEWAY_ADD_SERVICE	manage service-gateways
	DetachServiceId	SERVICE_GATEWAY_DELETE_SERVICE	manage service-gateways
	CreateServiceGateway	SERVICE_GATEWAY_CREATE	manage service-gateways
	UpdateServiceGateway	SERVICE_GATEWAY_UPDATE	manage service-gateways
	DeleteServiceGateway	SERVICE_GATEWAY_DELETE	manage service-gateways
	CreateRouteTable	SERVICE_GATEWAY_ATTACH	use service-gateways
	DeleteRouteTable	SERVICE_GATEWAY_DETACH	use service-gateways
	UpdateRouteTable	SERVICE_GATEWAY_ATTACH	use service-gateways
	UpdateRouteTable	SERVICE_GATEWAY_DETACH	use service-gateways
local-peering-gateways	ListLocalPeeringGateways	LOCAL_PEERING_GATEWAY_READ	inspect local-peering-gateways
	GetLocalPeeringGateway	LOCAL_PEERING_GATEWAY_READ	inspect local-peering-gateways
	CreateLocalPeeringGateway	LOCAL_PEERING_GATEWAY_CREATE	manage local-peering-gateways
	UpdateLocalPeeringGateway	LOCAL_PEERING_GATEWAY_UPDATE	manage local-peering-gateways
	DeleteLocalPeeringGateway	LOCAL_PEERING_GATEWAY_DELETE	manage local-peering-gateways
	ChangeLocalPeeringGatewayCompartment	LOCAL_PEERING_GATEWAY_MOVE	manage local-peering-gateways
	CreateRouteTable	LOCAL_PEERING_GATEWAY_ATTACH	manage local-peering-gateways
	DeleteRouteTable	LOCAL_PEERING_GATEWAY_DETACH	manage local-peering-gateways
	UpdateRouteTable	LOCAL_PEERING_GATEWAY_ATTACH	manage local-peering-gateways
	UpdateRouteTable	LOCAL_PEERING_GATEWAY_DETACH	manage local-peering-gateways
local-peering-from	ConnectLocalPeeringGateways	LOCAL_PEERING_GATEWAY_CONNECT_FROM	manage local-peering-from
local-peering-to	ConnectLocalPeeringGateways	LOCAL_PEERING_GATEWAY_CONNECT_TO	manage local-peering-to
remote-peering-connections	ListRemotePeeringConnections	REMOTE_PEERING_CONNECTION_READ	inspect remote-peering-connections
	GetRemotePeeringConnection	REMOTE_PEERING_CONNECTION_READ	inspect remote-peering-connections
	UpdateRemotePeeringConnection	REMOTE_PEERING_CONNECTION_UPDATE	manage remote-peering-connections
	CreateRemotePeeringConnection	REMOTE_PEERING_CONNECTION_CREATE	manage remote-peering-connections
	DeleteRemotePeeringConnection	REMOTE_PEERING_CONNECTION_DELETE	manage remote-peering-connections
	ChangeRemotePeeringConnectionCompartment	REMOTE_PEERING_CONNECTION_RESOURCE_MOVE	manage remote-peering-connections
remote-peering-from	ConnectRemotePeeringConnections	REMOTE_PEERING_CONNECTION_CONNECT_FROM	manage remote-peering-from
remote-peering-to	ConnectRemotePeeringConnections	REMOTE_PEERING_CONNECTION_CONNECT_TO	manage remote-peering-to
drgs	ListDrgs	DRG_READ	inspect drgs
	GetDrg	DRG_READ	inspect drgs
	CreateDrg	DRG_CREATE	manage drgs
	UpdateDrg	DRG_UPDATE	manage drgs
	DeleteDrg	DRG_DELETE	manage drgs
	ChangeDrgCompartment	DRG_MOVE	manage drgs
	CreateDrgAttachment	DRG_ATTACH	manage drgs
	DeleteDrgAttachment	DRG_DETACH	manage drgs
	CreateRouteTable	DRG_ATTACH	manage drgs
	DeleteRouteTable	DRG_DETACH	manage drgs
	UpdateRouteTable	DRG_ATTACH	manage drgs
	UpdateRouteTable	DRG_DETACH	manage drgs
drg-attachments	CreateDrgAttachment
	DeleteDrgAttachment
	ListDrgAttachments	DRG_ATTACHMENT_READ	inspect drg-attachments
	GetDrgAttachment	DRG_ATTACHMENT_READ	inspect drg-attachments
	UpdateDrgAttachment	DRG_ATTACHMENT_UPDATE	manage drg-attachments
cpes	ListCpes	CPE_READ	inspect cpes
	GetCpe	CPE_READ	inspect cpes
	CreateCpe	CPE_CREATE	manage cpes
	UpdateCpe	CPE_UPDATE	manage cpes
	DeleteCpe	CPE_DELETE	manage cpes
	ChangeCpeCompartment	CPE_RESOURCE_MOVE	manage cpes
ipsec	ListIPSecConnections	IPSEC_CONNECTION_READ	inspect ipsec
	GetIPSecConnection	IPSEC_CONNECTION_READ	inspect ipsec
	GetIPSecConnectionStatus	IPSEC_CONNECTION_READ	inspect ipsec
	ListIPSecConnectionTunnels	IPSEC_CONNECTION_READ	inspect ipsec
	GetIPSecConnectionTunnel	IPSEC_CONNECTION_READ	inspect ipsec
	GetTunnelCpeDeviceConfig	IPSEC_CONNECTION_READ	inspect ipsec
	GetTunnelCpeDeviceTemplateContent	IPSEC_CONNECTION_READ	inspect ipsec
	GetCpeDeviceTemplateContent	IPSEC_CONNECTION_READ	inspect ipsec
	GetIpsecCpeDeviceTemplateContent	IPSEC_CONNECTION_READ	inspect ipsec
	GetIPSecConnectionDeviceConfig	IPSEC_CONNECTION_DEVICE_CONFIG_READ	read ipsec
	GetIPSecConnectionTunnelSharedSecret	IPSEC_CONNECTION_DEVICE_CONFIG_READ	read ipsec
	UpdateIPSecConnection	IPSEC_CONNECTION_UPDATE	manage ipsec
	UpdateTunnelCpeDeviceConfig	IPSEC_CONNECTION_UPDATE	manage ipsec
	UpdateIPSecConnectionTunnel	IPSEC_CONNECTION_UPDATE	manage ipsec
	CreateIPSecConnection	IPSEC_CONNECTION_CREATE	manage ipsec
	DeleteIPSecConnection	IPSEC_CONNECTION_DELETE	manage ipsec
cross-connects	ListCrossConnects	CROSS_CONNECT_READ	inspect cross-connects
	GetCrossConnect	CROSS_CONNECT_READ	inspect cross-connects
	UpdateCrossConnect	CROSS_CONNECT_UPDATE	manage cross-connects
	CreateCrossConnect	CROSS_CONNECT_CREATE	manage cross-connects
	DeleteCrossConnect	CROSS_CONNECT_DELETE	manage cross-connects
	ChangeCrossConnectCompartment	CROSS_CONNECT_RESOURCE_MOVE	manage cross-connects
cross-connect-groups	ListCrossConnectGroups	CROSS_CONNECT_GROUP_READ	inspect cross-connect-groups
	GetCrossConnectGroup	CROSS_CONNECT_GROUP_READ	inspect cross-connect-groups
	UpdateCrossConnectGroup	CROSS_CONNECT_GROUP_UPDATE	manage cross-connect-groups
	CreateCrossConnectGroup	CROSS_CONNECT_GROUP_CREATE	manage cross-connect-groups
	DeleteCrossConnectGroup	CROSS_CONNECT_GROUP_DELETE	manage cross-connect-groups
	ChangeCrossConnectGroupCompartment	CROSS_CONNECT_GROUP_RESOURCE_MOVE	manage cross-connect-groups
virtual-circuits	ListVirtualCircuits	VIRTUAL_CIRCUIT_READ	inspect virtual-circuits
	GetVirtualCircuit	VIRTUAL_CIRCUIT_READ	inspect virtual-circuits
	ChangeVirtualCircuitCompartment	VIRTUAL_CIRCUIT_RESOURCE_MOVE	manage virtual-circuits
	CreateVirtualCircuit	VIRTUAL_CIRCUIT_CREATE	manage virtual-circuits
	DeleteVirtualCircuit	VIRTUAL_CIRCUIT_DELETE	manage virtual-circuits
vnics	GetVnic	VNIC_READ	inspect vnics
	AttachVnic	VNIC_ATTACH	use vnics
	AttachVnic	VNIC_CREATE	use vnics
	UpdateVnic	VNIC_UPDATE	use vnics
	DetachVnic	VNIC_DETACH	use vnics
	DetachVnic	VNIC_DELETE	use vnics
	LaunchInstance	VNIC_ATTACH	use vnics
	LaunchInstance	VNIC_CREATE	use vnics
	TerminateInstance	VNIC_DELETE	use vnics
	CreateInstancePool	VNIC_CREATE	use vnics
	TerminateInstancePool	VNIC_DELETE	use vnics
	CreateInstanceConfiguration	VNIC_READ	inspect vnics
	CreatePrivateIp	VNIC_ASSIGN	use vnics
	CreateMountTarget	VNIC_ASSIGN	use vnics
		VNIC_CREATE	use vnics
		VNIC_ATTACH	use vnics
	DeleteMountTarget	VNIC_UNASSIGN	use vnics
		VNIC_DELETE	use vnics
		VNIC_DETACH	use vnics
vnic-attachments	GetVnicAttachment	VNIC_ATTACHMENT_READ	inspect vnic-attachments
	ListVnicAttachments	VNIC_ATTACHMENT_READ	inspect vnic-attachments
	TerminateInstance
	CreateInstanceConfiguration	VNIC_ATTACHMENT_READ	inspect vnic-attachments
cluster-networks	ListClusterNetworks	CLUSTER_NETWORK_INSPECT	inspect cluster-networks
	GetClusterNetwork	CLUSTER_NETWORK_READ	read cluster-networks
	ListClusterNetworkInstances	CLUSTER_NETWORK_READ	read cluster-networks
	UpdateClusterNetwork	CLUSTER_NETWORK_UPDATE	manage cluster-networks
	ChangeClusterNetworkCompartment	CLUSTER_NETWORK_MOVE	manage cluster-networks
	CreateClusterNetwork	CLUSTER_NETWORK_CREATE	manage cluster-networks
	TerminateClusterNetwork	CLUSTER_NETWORK_DELETE	manage cluster-networks
dns-zones	ListZones	DNS_ZONE_INSPECT	inspect dns-zones
	CreateZone	DNS_ZONE_CREATE	manage dns-zones
	CreateChildZone	DNS_ZONE_CREATE	manage dns-zones
	InspectParentZone	DNS_ZONE_INSPECT	inspect dns-zones
	DeleteZone	DNS_ZONE_DELETE	manage dns-zones
	GetZone	DNS_ZONE_READ	read dns-zones
	UpdateZone	DNS_ZONE_UPDATE	use dns-zones
	ChangeZoneCompartment	DNS_ZONE_MOVE	manage dns-zones
	CreateSteeringPolicyAttachment	DNS_ZONE_UPDATE	use dns-zones
	UpdateSteeringPolicyAttachment	DNS_ZONE_UPDATE	use dns-zones
	DeleteSteeringPolicyAttachment	DNS_ZONE_UPDATE	use dns-zones
	GetZoneRecords	DNS_ZONE_READ	read dns-zones
	PatchZoneRecords	DNS_ZONE_UPDATE	use dns-zones
	UpdateZoneRecords	DNS_ZONE_UPDATE	use dns-zones
dns-records	GetZoneRecords	DNS_RECORD_READ	read dns-records
	PatchZoneRecords	DNS_RECORD_UPDATE	use dns-records
	UpdateZoneRecords	DNS_RECORD_UPDATE	use dns-records
	GetDomainRecords	DNS_RECORD_READ	read dns-records
	DeleteDomainRecords	DNS_RECORD_DELETE	manage dns-records
	PatchDomainRecords	DNS_RECORD_UPDATE	use dns-records
	UpdateDomainRecords	DNS_RECORD_UPDATE	use dns-records
	DeleteRRSet	DNS_RECORD_UPDATE	use dns-records
	GetRRSet	DNS_RECORD_READ	read dns-records
	PatchRRSet	DNS_RECORD_UPDATE	use dns-records
	UpdateRRSet	DNS_RECORD_UPDATE	use dns-records
dns-steering-policies	ListSteeringPolicies	DNS_STEERING_POLICY_INSPECT	inspect dns-steering-policies
	CreateSteeringPolicy	DNS_STEERING_POLICY_CREATE	manage dns-steering-policies
	GetSteeringPolicy	DNS_STEERING_POLICY_READ	read dns-steering-policies
	UpdateSteeringPolicy	DNS_STEERING_POLICY_UPDATE	use dns-steering-policies
	DeleteSteeringPolicy	DNS_STEERING_POLICY_DELETE	manage dns-steering-policies
	ChangeSteeringPolicyCompartment	DNS_STEERING_POLICY_MOVE	manage dns-steering-policies
	CreateSteeringPolicyAttachment	DNS_STEERING_POLICY_READ	read dns-steering-policies
	UpdateSteeringPolicyAttachment	DNS_STEERING_POLICY_READ	read dns-steering-policies
	DeleteSteeringPolicyAttachment	DNS_STEERING_POLICY_READ	read dns-steering-policies
dns-steering-policy-attachments	ListSteeringPolicyAttachments	DNS_STEERING_ATTACHMENT_INSPECT	inspect dns-steering-policy-attachments
	CreateSteeringPolicyAttachment
	GetSteeringPolicyAttachment	DNS_STEERING_ATTACHMENT_READ	read dns-steering-policy-attachments
	UpdateSteeringPolicyAttachment
	DeleteSteeringPolicyAttachment
dns-tsig-keys	ListTsigKeys	DNS_TSIG_KEY_INSPECT	inspect dns-tsig-keys
	CreateTsigKey	DNS_TSIG_KEY_CREATE	manage dns-tsig-keys
	GetTsigKey	DNS_TSIG_KEY_READ	read dns-tsig-keys
	UpdateTsigKey	DNS_TSIG_KEY_UPDATE	use dns-tsig-keys
	DeleteTsigKey	DNS_TSIG_KEY_DELETE	manage dns-tsig-keys
	ChangeTsigKeyCompartment	DNS_TSIG_KEY_MOVE	manage dns-tsig-keys
dns-views	ListViews	DNS_VIEW_INSPECT	inspect dns-views
	CreateView	DNS_VIEW_CREATE	manage dns-views
	GetView	DNS_VIEW_READ	read dns-views
	UpdateView	DNS_VIEW_UPDATE	use dns-views
	DeleteView	DNS_VIEW_DELETE	manage dns-views
	ChangeViewCompartment	DNS_VIEW_MOVE	manage dns-views
dns-resolvers	ListResolvers	DNS_RESOLVER_INSPECT	inspect dns-resolvers
	GetResolver	DNS_RESOLVER_READ	read dns-resolvers
	UpdateResolver	DNS_RESOLVER_UPDATE	use dns-resolvers
	ChangeResolverCompartment	DNS_RESOLVER_MOVE	manage dns-resolvers
dns-resolver-endpoint	ListResolverEndpoints	DNS_RESOLVER_ENDPOINT_INSPECT	inspect dns-resolver-endpoint
	CreateResolverEndpoint	DNS_RESOLVER_ENDPOINT_CREATE	manage dns-resolver-endpoint
	GetResolverEndpoint	DNS_RESOLVER_ENDPOINT_READ	read dns-resolver-endpoint
	UpdateResolverEndpoint	DNS_RESOLVER_ENDPOINT_UPDATE	use dns-resolver-endpoint
	DeleteResolverEndpoint	DNS_RESOLVER_ENDPOINT_DELETE	manage dns-resolver-endpoint
objectstorage-namespaces	GetNamespace
	GetNamespaceMetadata	OBJECTSTORAGE_NAMESPACE_READ	read objectstorage-namespaces
	UpdateNamespaceMetadata	OBJECTSTORAGE_NAMESPACE_UPDATE	manage objectstorage-namespaces
buckets	HeadBucket	BUCKET_INSPECT	inspect buckets
	ListBuckets	BUCKET_INSPECT	inspect buckets
	GetBucket	BUCKET_READ	read buckets
	ListMultipartUploads	BUCKET_READ	read buckets
	GetObjectLifecyclePolicy	BUCKET_READ	read buckets
	GetRetentionRule	BUCKET_READ	read buckets
	ListRetentionRules	BUCKET_READ	read buckets
	GetReplicationPolicy	BUCKET_READ	read buckets
	ListReplicationPolicies	BUCKET_READ	read buckets
	ListReplicationSources	BUCKET_READ	read buckets
	UpdateBucket	BUCKET_UPDATE	use buckets
	DeleteObjectLifecyclePolicy	BUCKET_UPDATE	use buckets
	ReencryptBucket	BUCKET_UPDATE	use buckets
	CreateBucket	BUCKET_CREATE	manage buckets
	DeleteBucket	BUCKET_DELETE	manage buckets
	CreatePar	PAR_MANAGE	manage buckets
	GetPar	PAR_MANAGE	manage buckets
	ListPars	PAR_MANAGE	manage buckets
	DeletePar	PAR_MANAGE	manage buckets
	CreateRetentionRule	RETENTION_RULE_LOCK	manage buckets
	UpdateRetentionRule	RETENTION_RULE_LOCK	manage buckets
	DeleteRetentionRule	RETENTION_RULE_LOCK	manage buckets
	MakeBucketWritable	BUCKET_READ	read buckets
	MakeBucketWritable	BUCKET_UPDATE	use buckets
	CreateReplicationPolicy	BUCKET_READ	read buckets
	CreateReplicationPolicy	BUCKET_UPDATE	use buckets
	DeleteReplicationPolicy	BUCKET_READ	read buckets
	DeleteReplicationPolicy	BUCKET_UPDATE	use buckets
	PutObjectLifecyclePolicy	BUCKET_UPDATE	use buckets
objects	HeadObject	OBJECT_INSPECT	inspect objects
	ListObjects	OBJECT_INSPECT	inspect objects
	ListMultipartUploadParts	OBJECT_INSPECT	inspect objects
	CreateObject	OBJECT_CREATE	manage objects
	GetObject	OBJECT_READ	read objects
	ReencryptObject	OBJECT_OVERWRITE	use objects
	RenameObject	OBJECT_CREATE	manage objects
	RenameObject	OBJECT_OVERWRITE	use objects
	RestoreObject	OBJECT_RESTORE	manage objects
	DeleteObject	OBJECT_DELETE	manage objects
	DeleteObjectVersion	OBJECT_VERSION_DELETE	manage objects
	CreateMultipartUpload	OBJECT_CREATE	manage objects
	CreateMultipartUpload	OBJECT_OVERWRITE	use objects
	UploadPart	OBJECT_CREATE	manage objects
	UploadPart	OBJECT_OVERWRITE	use objects
	CommitMultipartUpload	OBJECT_CREATE	manage objects
	CommitMultipartUpload	OBJECT_OVERWRITE	use objects
	AbortMultipartUpload	OBJECT_DELETE	manage objects
	PutObject	OBJECT_CREATE	manage objects
	('PutObject', 'overwrite')	OBJECT_OVERWRITE	use objects
	CreateCopyRequest	OBJECT_READ	read objects
		OBJECT_CREATE	manage objects
		OBJECT_OVERWRITE	use objects
		OBJECT_INSPECT	inspect objects
	CopyObject	OBJECT_READ	read objects
		OBJECT_CREATE	manage objects
		OBJECT_OVERWRITE	use objects
		OBJECT_INSPECT	inspect objects
export-sets	CreateExport	EXPORT_SET_UPDATE	manage export-sets
	GetExport	EXPORT_SET_READ	read export-sets
	ListExports	EXPORT_SET_READ	read export-sets
	UpdateExport	EXPORT_SET_UPDATE	manage export-sets
	DeleteExport	EXPORT_SET_UPDATE	manage export-sets
	CreateExportSet	EXPORT_SET_CREATE	manage export-sets
	GetExportSet	EXPORT_SET_READ	read export-sets
	ListExportSets	EXPORT_SET_INSPECT	inspect export-sets
	UpdateExportSet	EXPORT_SET_UPDATE	manage export-sets
	DeleteExportSet	EXPORT_SET_DELETE	manage export-sets
file-systems	ListFileSystems	FILE_SYSTEM_INSPECT	inspect file-systems
	GetFileSystem	FILE_SYSTEM_READ	read file-systems
	CreateFileSystem	FILE_SYSTEM_CREATE	manage file-systems
	UpdateFileSystem	FILE_SYSTEM_UPDATE	manage file-systems
	DeleteFileSystem	FILE_SYSTEM_DELETE	manage file-systems
	ChangeFileSystemCompartment	FILE_SYSTEM_MOVE	manage file-systems
	CreateSnapshot	FILE_SYSTEM_CREATE_SNAPSHOT	manage file-systems
	DeleteSnapshot	FILE_SYSTEM_DELETE_SNAPSHOT	manage file-systems
	GetSnapshot	FILE_SYSTEM_READ	read file-systems
	ListSnapshots	FILE_SYSTEM_READ	read file-systems
	UpdateSnapshot	FILE_SYSTEM_UPDATE	manage file-systems
mount-targets	ListMountTargets	MOUNT_TARGET_INSPECT	inspect mount-targets
	GetMountTarget	MOUNT_TARGET_READ	read mount-targets
	UpdateMountTarget	MOUNT_TARGET_UPDATE	manage mount-targets
	ChangeMountTargetCompartment	MOUNT_TARGET_MOVE	manage mount-targets
	CreateMountTarget	MOUNT_TARGET_CREATE	manage mount-targets
	DeleteMountTarget	MOUNT_TARGET_DELETE	manage mount-targets
volumes	ListVolumes	VOLUME_INSPECT	inspect volumes
	GetVolume	VOLUME_INSPECT	inspect volumes
	UpdateVolume	VOLUME_UPDATE	use volumes
	GetBootVolume	VOLUME_INSPECT	inspect volumes
	ListBootVolumes	VOLUME_INSPECT	inspect volumes
	UpdateBootVolume	VOLUME_UPDATE	use volumes
	DeleteBootVolume	VOLUME_DELETE	manage volumes
	CreateVolume	VOLUME_CREATE	manage volumes
	CreateBootVolume	VOLUME_CREATE	manage volumes
	DeleteVolume	VOLUME_DELETE	manage volumes
	AttachVolume	VOLUME_WRITE	use volumes
	DetachVolume	VOLUME_WRITE	use volumes
	TerminateInstance	VOLUME_WRITE	use volumes
	ListVolumeAttachments	VOLUME_INSPECT	inspect volumes
	ListBootVolumeAttachments	VOLUME_INSPECT	inspect volumes
	GetVolumeAttachment	VOLUME_INSPECT	inspect volumes
	GetBootVolumeAttachment	VOLUME_INSPECT	inspect volumes
	ChangeVolumeCompartment	VOLUME_MOVE	manage volumes
	ChangeBootVolumeCompartment	BOOT_VOLUME_MOVE	manage volumes
	TerminateInstancePool	VOLUME_WRITE	use volumes
	CreateInstanceConfiguration	VOLUME_INSPECT	inspect volumes
	CreateBootVolumeBackup	VOLUME_WRITE	use volumes
	UpdateVolumeBackup	VOLUME_INSPECT	inspect volumes
	UpdateBootVolumeBackup	VOLUME_INSPECT	inspect volumes
	ListVolumeBackups	VOLUME_INSPECT	inspect volumes
	CreateVolumeGroupBackup	VOLUME_WRITE	use volumes
	CreateVolumeGroup	VOLUME_INSPECT	inspect volumes
		VOLUME_CREATE	manage volumes
		VOLUME_WRITE	use volumes
	UpdateVolumeGroup	VOLUME_INSPECT	inspect volumes
	DeleteVolumeBackup	VOLUME_INSPECT	inspect volumes
	GetVolumeBackupPolicyAssetAssignment	VOLUME_INSPECT	inspect volumes
	ChangeVolumeGroupCompartment	VOLUME_MOVE	manage volumes
	ChangeVolumeGroupCompartment	BOOT_VOLUME_MOVE	manage volumes
volume-attachments	ListVolumeAttachments	VOLUME_ATTACHMENT_INSPECT	inspect volume-attachments
	ListBootVolumeAttachments	VOLUME_ATTACHMENT_INSPECT	inspect volume-attachments
	GetVolumeAttachment	VOLUME_ATTACHMENT_INSPECT	inspect volume-attachments
	GetBootVolumeAttachment	VOLUME_ATTACHMENT_INSPECT	inspect volume-attachments
	AttachVolume	VOLUME_ATTACHMENT_CREATE	manage volume-attachments
	AttachBootVolume	VOLUME_ATTACHMENT_CREATE	manage volume-attachments
	DetachVolume	VOLUME_ATTACHMENT_DELETE	manage volume-attachments
	DetachBootVolume	VOLUME_ATTACHMENT_DELETE	manage volume-attachments
	TerminateInstance	VOLUME_ATTACHMENT_DELETE	manage volume-attachments
	TerminateInstancePool	VOLUME_ATTACHMENT_DELETE	manage volume-attachments
	CreateInstanceConfiguration	VOLUME_ATTACHMENT_INSPECT	inspect volume-attachments
volume-backups	ListVolumeBackups	VOLUME_BACKUP_INSPECT	inspect volume-backups
	GetVolumeBackup	VOLUME_BACKUP_INSPECT	inspect volume-backups
	UpdateVolumeBackup	VOLUME_BACKUP_UPDATE	use volume-backups
	CopyVolumeBackup	VOLUME_BACKUP_COPY	use volume-backups
	CreateVolumeBackup	VOLUME_BACKUP_CREATE	manage volume-backups
	DeleteVolumeBackup	VOLUME_BACKUP_DELETE	manage volume-backups
	CreateVolume	VOLUME_BACKUP_READ	read volume-backups
	CreateVolumeGroupBackup	VOLUME_BACKUP_CREATE	manage volume-backups
	CreateVolumeGroup	VOLUME_BACKUP_READ	read volume-backups
	DeleteVolumeGroupBackup	VOLUME_BACKUP_DELETE	manage volume-backups
	ChangeVolumeBackupCompartment	VOLUME_BACKUP_MOVE	manage volume-backups
	ChangeVolumeGroupBackupCompartment	VOLUME_BACKUP_MOVE	manage volume-backups
boot-volume-backups	ListBootVolumeBackups	BOOT_VOLUME_BACKUP_INSPECT	inspect boot-volume-backups
	GetBootVolumeBackup	BOOT_VOLUME_BACKUP_INSPECT	inspect boot-volume-backups
	CreateBootVolume	BOOT_VOLUME_BACKUP_READ	read boot-volume-backups
	UpdateBootVolumeBackup	BOOT_VOLUME_BACKUP_UPDATE	use boot-volume-backups
	CopyBootVolumeBackup	BOOT_VOLUME_BACKUP_COPY	use boot-volume-backups
	CreateBootVolumeBackup	BOOT_VOLUME_BACKUP_CREATE	manage boot-volume-backups
	DeleteBootVolumeBackup	BOOT_VOLUME_BACKUP_DELETE	manage boot-volume-backups
	CreateVolumeGroupBackup	BOOT_VOLUME_BACKUP_CREATE	manage boot-volume-backups
	CreateVolumeGroup	BOOT_VOLUME_BACKUP_READ	read boot-volume-backups
	DeleteVolumeGroupBackup	BOOT_VOLUME_BACKUP_DELETE	manage boot-volume-backups
	ChangeVolumeBackupCompartment	BOOT_VOLUME_BACKUP_MOVE	manage boot-volume-backups
	ChangeBootVolumeBackupCompartment	BOOT_VOLUME_BACKUP_MOVE	manage boot-volume-backups
	ChangeVolumeGroupBackupCompartment	BOOT_VOLUME_BACKUP_MOVE	manage boot-volume-backups
backup-policies	ListVolumeBackupPolicies	BACKUP_POLICIES_INSPECT	inspect backup-policies
	GetVolumeBackupPolicy	BACKUP_POLICIES_INSPECT	inspect backup-policies
	UpdateVolumeBackupPolicy	BACKUP_POLICIES_UPDATE	use backup-policies
	CreateVolumeBackupPolicy	BACKUP_POLICIES_CREATE	manage backup-policies
	DeleteVolumeBackupPolicy	BACKUP_POLICIES_DELETE	manage backup-policies
backup-policy-assignments	GetVolumeBackupPolicyAssignment	BACKUP_POLICY_ASSIGNMENT_INSPECT	inspect backup-policy-assignments
	GetVolumeBackupPolicyAssetAssignment	BACKUP_POLICY_ASSIGNMENT_INSPECT	inspect backup-policy-assignments
	CreateVolumeBackupPolicyAssignment	BACKUP_POLICY_ASSIGNMENT_CREATE	manage backup-policy-assignments
	DeleteVolumeBackupPolicyAssignment	BACKUP_POLICY_ASSIGNMENT_DELETE	manage backup-policy-assignments
volume-groups	ListVolumeGroups	VOLUME_GROUP_INSPECT	inspect volume-groups
	GetVolumeGroup	VOLUME_GROUP_INSPECT	inspect volume-groups
	DeleteVolumeGroup	VOLUME_GROUP_DELETE	manage volume-groups
	UpdateVolumeGroup	VOLUME_GROUP_UPDATE	manage volume-groups
	CreateVolumeGroup	VOLUME_GROUP_CREATE	manage volume-groups
	CreateVolumeGroupBackup	VOLUME_GROUP_INSPECT	inspect volume-groups
	ChangeVolumeGroupCompartment	VOLUME_GROUP_MOVE	manage volume-groups
volume-group-backups	ListVolumeGroupBackups	VOLUME_GROUP_BACKUP_INSPECT	inspect volume-group-backups
	GetVolumeGroupBackup	VOLUME_GROUP_BACKUP_INSPECT	inspect volume-group-backups
	UpdateVolumeGroupBackup	VOLUME_GROUP_BACKUP_UPDATE	manage volume-group-backups
	CreateVolumeGroupBackup	VOLUME_GROUP_BACKUP_CREATE	manage volume-group-backups
	DeleteVolumeGroupBackup	VOLUME_GROUP_BACKUP_DELETE	manage volume-group-backups
	CreateVolumeGroup	VOLUME_GROUP_BACKUP_INSPECT	inspect volume-group-backups
	ChangeVolumeGroupBackupCompartment	VOLUME_GROUP_BACKUP_MOVE	manage volume-group-backups
clusters	ListClusters	CLUSTER_INSPECT	inspect clusters
	CreateCluster	CLUSTER_CREATE	manage clusters
	GetClusterKubeconfig	CLUSTER_USE	use clusters
	GetCluster	CLUSTER_READ	read clusters
	UpdateCluster	CLUSTER_UPDATE	manage clusters
	DeleteCluster	CLUSTER_DELETE	manage clusters
	AdministerK8s	CLUSTER_MANAGE	manage clusters
cluster-node-pools	ListNodePools	CLUSTER_NODE_POOL_INSPECT	inspect cluster-node-pools
	CreateNodePool	CLUSTER_NODE_POOL_CREATE	manage cluster-node-pools
	GetNodePool	CLUSTER_NODE_POOL_READ	read cluster-node-pools
	GetNodePoolOptions
	UpdateNodePool	CLUSTER_NODE_POOL_UPDATE	manage cluster-node-pools
	DeleteNodePool	CLUSTER_NODE_POOL_DELETE	manage cluster-node-pools