Common Policies

This section includes some common policies you might want to use in your organization.

Note

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 (see Let group admins manage group membership).

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.
  • The operation to view Audit service events requires the read verb instead of inspect.

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

Allow group Auditors to read audit-events 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, virtual circuits, security lists, route tables, and so on. If the network admins need to launch instances to test network connectivity, see Let users launch Compute instances on this page.

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 network admins manage load balancers

Type of access: Ability to manage all components in Load Balancing. If the group needs to launch instances, see Let users launch Compute instances on this page.

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, NetworkAdmins can then manage load balancers 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 load-balancers in tenancy

If the group uses the Console to manage load balancers, an additional policy to use the associated networking resources is required:

Allow group NetworkAdmins to manage load-balancers in tenancy

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

If a particular group needs to update existing load balancers (for example, modify the backend set) but not create or delete them, use this statement:

Allow group LBUsers to use load-balancers 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. If the group doesn't need to attach/detach volumes, you can delete the third statement.

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, see Policy Attachment.

Allow group InstanceLaunchers to manage instance-family in compartment ABC

Allow group InstanceLaunchers to read app-catalog-listing in tenancy

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 dedicated virtual machine hosts

Type of access: Ability to create, update, and delete dedicated virtual machine hosts as well as launch instances on dedicated virtual machine hosts.

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 dedicated virtual machine hosts and instances in a particular compartment, specify that compartment instead of the tenancy.

Allow group DedicatedVMHostAdmins to manage dedicated-vm-hosts in tenancy

Allow group DedicatedVMHostAdmins to manage instances in tenancy
Let users launch Compute instances on dedicated virtual machine hosts

Type of access: Ability to launch instances on dedicated virtual machine hosts.

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 dedicated virtual machine hosts and instances in a particular compartment, specify that compartment instead of the tenancy.

Allow group DedicatedVMHostAdmins to use dedicated-vm-hosts in tenancy

Allow group DedicatedVMHostAdmins to manage instances in tenancy
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, SDKs, or command line interface (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
Let users manage Compute autoscaling configurations

Type of access: Ability to create, update, and delete autoscaling configurations.

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 autoscaling configurations in a particular compartment, specify that compartment instead of the tenancy.

Allow group AutoscalingAdmins to manage auto-scaling-configurations in tenancy

Allow group AutoscalingAdmins to manage instance-pools in tenancy
Let users list and subscribe to images from the Partner Image catalog

Type of access: Ability to list and create subscriptions to images in the Partner Image catalog. It does not include the ability to create instances using images from the Partner Image catalog (see Let users launch Compute instances).

Where to create the policy: In the tenancy. To reduce the scope of access to just creating subscriptions in a particular compartment, specify that compartment instead of the tenancy in the third statement.

Allow group CatalogSubscribers to inspect app-catalog-listing in tenancy

Allow group CatalogSubscribers to read app-catalog-listing in tenancy

Allow group CatalogSubscribers to manage app-catalog-listing in tenancy
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

If the group needs to also copy volume backups and boot volume backups across regions, add the following statements to the policy:

Allow group VolumeAdmins to use volume-backups in tenancy where request.permission='VOLUME_BACKUP_COPY'
Allow group VolumeAdmins to use boot-volume-backups in tenancy where request.permission='BOOT_VOLUME_BACKUP_COPY'
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 will be using the Console, the following policy gives 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 necessary in order to manage volume backups. However, they enable the Console to display all the information about a particular volume and the 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 will be using the Console, the following policy gives 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 necessary in order to manage volume backups. However, they enable the Console to display all the information about a particular boot volume and the 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 using the Console. It enables the Console 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 (imagine a situation where a client needs to regularly write log files to a bucket). This consists of 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, see Policy Attachment.

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

Access limited to a specific bucket: 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'}}

For more information about using conditions, see Advanced Policy Features.

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.

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, see Policy Attachment.

Allow group ObjectReaders to read buckets in compartment ABC

Allow group ObjectReaders to read objects in compartment ABC

Access limited to a specific bucket: 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'

For more information about using conditions, see Advanced Policy Features.

Let database admins manage Oracle Cloud database systems
Type of access: Ability to do all things with the following system types and their associated resources in all compartments:
  • Exadata Cloud Service instances
  • bare metal DB systems
  • virtual machine DB systems

This makes sense if you want to have a single set of database admins manage all the bare metal, virtual machine, and Exadata systems in all the 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 database systems in a particular compartment, specify that compartment instead of the tenancy.

Allow group DatabaseAdmins to manage database-family in tenancy
Let database admins manage Exadata Cloud@Customer instances

Type of access: Ability to do all things with the Exadata Cloud@Customer resources in all compartments. This makes sense if you want to have a single set of database admins manage all the Exadata Cloud@Customer systems in all the 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 Exadata Cloud@Customer

systems in a particular compartment, specify that compartment instead of the tenancy.

Allow group ExaCCAdmins to manage database-family in tenancy
Let database and fleet admins manage Autonomous Databases

Type of access: Ability to do all things with Autonomous Database instances in all compartments. Applicable if you want to have a single set of database administrators manage all the Autonomous Database databases in all the compartments.

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

Example 1: For fleet administrators. Enables Autonomous Database fleet administrator access to the various workload types (Autonomous Data Warehouse, Autonomous JSON Database, and Autonomous Transaction Processing), and to dedicated Exadata infrastructure resources (container databases and Autonomous Exadata Infrastructure instances).

Allow group DatabaseAdmins to manage autonomous-database-family in tenancy

If you must restrict access to the Autonomous Exadata Infrastructure and Autonomous Container Database resource types (applicable only to dedicated Exadata infrastructure systems), then you can do so by creating separate policy statements for database administrators that allow access to only Autonomous Databases and their backups. Because a policy statement can only specify one resource type, you must create separate statements for the database and backup resources.

Example 2: For database administrators. Enables Autonomous Database database administrators access to databases and backups of the various workload types, but denies access to Autonomous Container Databases and Autonomous Exadata Infrastructure instances.

Allow group ADB-Admins to manage autonomous-database in tenancy
Allow group ADB-Admins to manage autonomous-backup in tenancy

To reduce the scope of access to either the Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing workload types, use a where clause, as shown in the next example.

Example 3: For database administrators. Limits Autonomous Database access to Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing databases and backups.

Allow group ADB-Admins to manage autonomous-database in tenancy where target.workloadType = 'workload_type'
Allow group ADB-Admins to manage autonomous-backup in tenancy where target.workloadType = 'workload_type'

In the preceding code examples, workload_type can be DW, AJD, or OLTP for Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing, respectively.

Let security admins manage vaults, keys, and secrets

Type of access: Ability to do all things with the Vault service in all compartments. This makes sense if you want to have a single set of security admins manage all the vaults, keys, and secret components (including secrets, secret versions, and secret bundles) in all compartments.

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

Allow group SecurityAdmins to manage vaults in tenancy

Allow group SecurityAdmins to manage keys in tenancy

Allow group SecurityAdmins to manage secret-family in tenancy
Let security admins manage all keys in a specific vault in a compartment

Type of access: Ability to do all things with keys in a specific vault 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 compartment (ABC) to have control over the individual policy statements for their compartment, see Policy Attachment.

Allow group SecurityAdmins to manage keys in compartment ABC where target.vault.id='<vault_OCID>'
Let security admins use a specific key in a compartment

Type of access: Ability to list, view, and perform cryptographic operations with a specific key in a compartment.

Where to create the policy: The easiest approach is to put this policy in the tenancy. If you want the admins of the individual compartment (ABC) to have control over the individual policy statements for their compartment, see Policy Attachment.

Allow group SecurityAdmins to use keys in compartment ABC where target.key.id='<key_OCID>'
Let a user group delegate key usage in a compartment

Type of access: Ability to associate an Object Storage bucket, Block Volume volume, File Storage file system, Kubernetes cluster, or Streaming stream pool with a specific key authorized for use in a specific compartment. With this policy, a user in the specified group does not have permission to use the key itself. Rather, by association, the key can be used by Object Storage, Block Volume, File Storage, Container Engine for Kubernetes, or Streaming on behalf of the user to:

  • Create or update an encrypted bucket, volume, or file system and to encrypt or decrypt data in the bucket, volume, or file system.
  • Create Kubernetes clusters with encrypted Kubernetes secrets at rest in the etcd key-value store.
  • Create a stream pool to encrypt data in the streams in the stream pool.

This policy requires that you also have a companion policy that lets Object Storage, Block Volume, File Storage, Container Engine for Kubernetes, or Streaming use the key to perform cryptographic operations.

Where to create the policy: The easiest approach is to put this policy in the tenancy. If you want the admins of the individual compartment (ABC) to have control over the individual policy statements for their compartment, see Policy Attachment.

Allow group ObjectWriters, VolumeWriters, FileWriters, ClusterWriters, StreamWriters to use key-delegate in compartment ABC where target.key.id = '<key_OCID>'
Let Block Volume, Object Storage, File Storage, Container Engine for Kubernetes, and Streaming services encrypt and decrypt volumes, volume backups, buckets, file systems, Kubernetes secrets, and stream pools

Type of access: Ability to list, view, and perform cryptographic operations with all keys in compartment ABC. Because Object Storage is a regional service, it has regional endpoints. As such, you must specify the regional service name for each region where you’re using Object Storage with Vault encryption. This policy also requires that you have a companion policy that allows a user group to use the delegated key that Object Storage, Block Volume, File Storage, Container Engine for Kubernetes, or Streaming will use.

Where to create the policy: The easiest approach is to put this policy in the tenancy. If you want the admins of the individual compartment (ABC) to have control over the individual policy statements for their compartment, see Policy Attachment.

Allow service blockstorage, objectstorage-<region_name>, FssOc1Prod, oke, streaming to use keys in compartment ABC where target.key.id = '<key_OCID>'

For Object Storage, replace <region_name> with the appropriate region identifier, for example:

  • objectstorage-us-phoenix-1

  • objectstorage-us-ashburn-1

  • objectstorage-eu-frankfurt-1

  • objectstorage-uk-london-1

  • objectstorage-ap-tokyo-1

To determine the region name value of an Oracle Cloud Infrastructure region, see Regions and Availability Domains.

For File Storage, the service name used in the policy is FssOc1Prod.

For Container Engine for Kubernetes, the service name used in the policy is oke.

For Streaming, the service name used in the policy is streaming.

Let security admins manage all secrets in a specific vault in a compartment

Type of access: Ability to do all things with secrets in a specific vault 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 compartment (ABC) to have control over the individual policy statements for their compartment, see Policy Attachment.

Allow group SecurityAdmins to manage secret-family in compartment ABC where target.vault.id='<vault_OCID>'
Let users read, update, and rotate all secrets

Type of access: Ability to read, update, and rotate all secrets in any vault in the tenancy.

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

Allow group SecretsUsers to use secret-family in tenancy
Let group admins manage group membership

Type of access: Ability to manage the membership of a group. Does not include the ability to create or delete users, or manage their credentials (see Let the Help Desk manage users).

The first two statements let GroupAdmins list all the users and groups in the tenancy, list which users are in a particular group, and list what groups a particular user is in.

The last two statements together let GroupAdmins change a group's membership. The condition at the end of the last two statements lets GroupAdmins manage membership to all groups except the Administrators group (see The Administrators Group and Policy). You should protect membership to that group because it has power to do anything throughout the tenancy.

It might seem that the last two statements should also cover the basic listing functionality that the first two statements enable. To better understand how conditions work and why you also need the first two statements, see Variables that Aren't Applicable to a Request Result in a Declined Request.

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

Allow group GroupAdmins to inspect users in tenancy

Allow group GroupAdmins to inspect groups in tenancy

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'
Let users manage their own passwords and credentials

No policy is required to let users manage their own credentials. All users have the ability to change and reset their own passwords, manage their own API keys, and manage their own auth tokens. For more information, see User Credentials.

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. For more information, see Policy Attachment. For an example of this kind of setup and additional policies that are useful, see Example Scenario.

Where to create the policy: In the tenancy.

Allow group A-Admins to manage all-resources in compartment Project-A
Restrict admin access to a specific region

Type of access: Ability to manage resources in a specific region. Remember that IAM resources must be managed in the home region. If the specified region is not the home region, then the Admin will not be able to manage IAM resources. For more information about the home region, see Managing Regions.

Where to create the policy: In the tenancy.

Allow group PHX-Admins to manage all-resources in tenancy where request.region='phx'

The preceding policy allows PHX-Admins to manage all aspects of all resources in US West (Phoenix).

Members of the PHX-Admins group can only manage IAM resources if the tenancy's home region is US West (Phoenix).

Restrict user access to view only summary announcements

Type of access: Ability to view the summary versions of announcements about the operational status of Oracle Cloud Infrastructure services.

Where to create the policy: In the tenancy.

Allow group AnnouncementListers to inspect announcements in tenancy

The preceding policy allows AnnouncementListers to view a list of summary announcements.

Let users view details of announcements

Type of access: Ability to view the details of announcements about the operational status of Oracle Cloud Infrastructure services.

Where to create the policy: In the tenancy.

Allow group AnnouncementReaders to read announcements in tenancy

The preceding policy allows AnnouncementReaders to view a list of summary announcements and the details of specific announcements.

Let streaming users manage streams

Type of access: Ability to do all things with the Streaming service 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 streams in a particular compartment, specify that compartment instead of the tenancy.

Allow group StreamAdmins to manage streams in tenancy
Let streaming users publish messages to streams

Type of access: Ability to produce messages to streams with the Streaming service 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 streams in a particular compartment, specify that compartment instead of the tenancy.

Allow group StreamUsers to use stream-push in tenancy
Let streaming users publish messages to a specific stream

Type of access: Ability to produce messages to a stream with the Streaming service.

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 streams in a particular compartment, specify that compartment instead of the tenancy.

Allow group StreamUsers to use stream-push in tenancy where target.stream.id = '<stream_OCID>'
Let streaming users consume messages from streams

Type of access: Ability to consume messages from streams with the Streaming service 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 streams in a particular compartment, specify that compartment instead of the tenancy.

Allow group StreamUsers to use stream-pull in tenancy
Let users view metric definitions in a compartment

Type of access: Ability to view metric definitions  in a specific compartment. For more information about metrics, see Metrics Feature Overview.

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 metric definitions in a particular compartment, specify that compartment instead of the tenancy.

Allow group MetricReaders to inspect metrics in compartment ABC
Let users access monitoring metrics in a compartment

Type of access: Ability to view and retrieve monitoring metrics  for supported resources in a specific compartment. For more information about metrics, see Metrics Feature Overview.

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 metrics in a particular compartment, specify that compartment instead of the tenancy.

Allow group MetricReaders to read metrics in compartment ABC
Restrict user access to a specific metric namespace

Type of access: Ability to view and retrieve monitoring metrics  for resources under a specific metric namespace . For more information about metrics, see Metrics Feature Overview.

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 the specified metric namespace to just within a particular compartment, specify that compartment instead of the tenancy.

Allow group MetricReaders to read metrics in compartment ABC where target.metrics.namespace='oci_computeagent'

The preceding policy allows MetricReaders to view and retrieve metric data points from all monitoring-enabledCompute instances in the ABC compartment.

Let users publish custom metrics

Type of access: Ability to publish custom metrics  under a specific metric namespace  to the Monitoring service. For instructions, see Publishing Custom Metrics.

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 metrics in a particular compartment, specify that compartment instead of the tenancy.

Allow group MetricPublishers to use metrics in tenancy where target.metrics.namespace='mycustomnamespace'

The preceding policy allows MetricPublishers to publish data points for the custom metric namespace mycustomnamespace in the tenancy.

Let instances make API calls to access monitoring metrics in the tenancy

Type of access: Ability to call the Monitoring API for access to monitoring metrics . The instances on which API requests originate must be members of the dynamic group indicated in the policy. For more information, see Calling Services from an Instance and Metrics Feature Overview.

Where to create the policy: In the tenancy.

Allow dynamic-group MetricInstances to read metrics in tenancy

The preceding policy allows applications that are running on Compute instances in the dynamic group MetricInstances to send API requests to the Monitoring service in the tenancy.

Let users view alarms

Type of access: Ability to view alarms  for supported resources in tenancy. Does not include the ability to create alarms or to create or delete topics. For more information about alarms, see Alarms Feature Overview.

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

Allow group AlarmUsers to read alarms in tenancy

Allow group AlarmUsers to read metrics in tenancy
Let users manage alarms

Type of access: Ability to view and create alarms  with existing notification topics for supported resources in the tenancy. Does not include the ability to create or delete topics. For more information about alarms, see Alarms Feature Overview.

All statements are required to let AlarmUsers create alarms.

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, AlarmUsers can then view and create alarms in any compartment. To reduce the scope of access to a particular compartment, specify that compartment instead of the tenancy.

Allow group AlarmUsers to manage alarms in tenancy

Allow group AlarmUsers to read metrics in tenancy

Allow group AlarmUsers to use ons-topics in tenancy
Let users manage alarms and create topics

Type of access: Ability to view and create alarms  (with new or existing topics ) for supported resources in tenancy. Also includes the ability to create subscriptions  in the tenancy, to publish messages  (broadcast notification messages) to all subscriptions in the tenancy, and to move alarms to different compartments in the tenancy. For more information about alarms, see Alarms Feature Overview.

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, AlarmUsers can then view and create alarms in any compartment. To reduce the scope of access to a particular compartment, specify that compartment instead of the tenancy.

Allow group AlarmUsers to manage alarms in tenancy

Allow group AlarmUsers to read metrics in tenancy

Allow group AlarmUsers to manage ons-topics in tenancy
Let users access usage reports

Type of access: Ability to view usage reports for your tenancy. For more information about usage reports, see Cost and Usage Reports Overview.

Where to create the policy: This is a special cross-tenancy policy and must be created in the tenancy. For more information, see Cost and Usage Reports Overview.

define tenancy usage-report as ocid1.tenancy.oc1..aaaaaaaaned4fkpkisbwjlr56u7cj63lf3wffbilvqknstgtvzub7vhqkggq
				endorse group Administrators to read objects in tenancy usage-report
Let users analyze costs

Type of access: Ability to see costs for the tenancy. See Checking Your Balance and Usage.

Where to create the policy: In the tenancy so that users in the <Example_Group> can see costs for the entire account.

Allow group <Example_Group> to read usage-reports in tenancy
Allow a group to manage topics

Type of access: Ability to get, create, update, and delete topics  in the tenancy, as well as move topics to different compartments in the tenancy. Also includes the ability to create subscriptions  in the tenancy and to publish messages  (broadcast notification messages) to all subscriptions in the tenancy.

Where to create the policy: In the tenancy.

Allow group A-Admins to manage ons-topics in tenancy
Allow a group to manage topic subscriptions

Type of access: Ability to list, create, update, and delete subscriptions  for topics in the tenancy. Ability to move subscriptions to different compartments in the tenancy.

Where to create the policy: In the tenancy.

Allow group A-Admins to manage ons-subscriptions in tenancy
Allow a group to publish messages to topics

Type of access: Ability to broadcast notification messages  to all subscriptions  in the tenancy, as well as list, create, update, and delete subscriptions in the tenancy.

Where to create the policy: In the tenancy.

Allow group A-Admins to use ons-topics in tenancy
Let users list Events rules in a compartment

Type of access: Ability to list Events rules.

Where to create the policy: In the tenancy.

Allow group RuleReaders to read cloudevents-rules in tenancy

The preceding policy allows RuleReaders to list rules in the tenancy.

Let admins manage Events rules in a compartment

Type of access: Ability to manage Events rules, including creating, deleting and updating rules.

Where to create the policy: In the tenancy.

This line gives the user inspect access to resources in compartments to select actions.

allow group <RuleAdmins> to inspect compartments in tenancy

This line gives the user access to defined tags to apply filter tags to rules.

allow group <RuleAdmins> to use tag-namespaces in tenancy

These lines give the user access to Streaming resources for actions

allow group <RuleAdmins> to inspect streams in tenancy
allow group <RuleAdmins> to use stream-push in tenancy
allow group <RuleAdmins> to use stream-pull in tenancy

These lines give the user access to Functions resources for actions.

allow group <RuleAdmins> to use virtual-network-family in tenancy
allow group <RuleAdmins> to manage function-family in tenancy

This line give the user access to Notifications topics for actions.

allow group <RuleAdmins> to use ons-topic in tenancy

This line gives the user manage access to rules for Events.

allow group <RuleAdmins> to manage cloudevents-rules in tenancy
Allow a group to access all of Cloud Guard

Type of access: Read-only access to all of Cloud Guard. In the example policy, the group is "CloudGuard_ReadOnly."

allow group CloudGuard_ReadOnly to read cloud-guard-family in tenancy
allow group CloudGuard_ReadOnly to read compartments in tenancy
allow group CloudGuard_ReadOnly to read announcements in tenancy
Allow a group to access Cloud Guard problems

Type of access: Read-only access to Cloud Guard problems. In the example policy, the group is "CloudGuard_ReadOnlyProblems."

allow group CloudGuard_ReadOnlyProblems to read cloud-guard-family in tenancy
allow group CloudGuard_ReadOnlyProblems to inspect cloud-guard-detectors in tenancy
allow group CloudGuard_ReadOnlyProblems to inspect cloud-guard-targets in tenancy
allow group CloudGuard_ReadOnlyProblems to inspect cloud-guard-resource-types in tenancy
allow group CloudGuard_ReadOnlyProblems to read announcements in tenancy
allow group CloudGuard_ReadOnlyProblems to read compartments in tenancy
allow group CloudGuard_ReadOnlyProblems to read cloud-guard-config in tenancy
Allow a group to access Cloud Guard detector recipes

Type of access: Read-only access to Cloud Guard detector recipes. In the example policy, the group is "CloudGuard_ReadOnlyDetectors."

allow group CloudGuard_ReadOnlyDetectors to read cloud-guard-detector-recipes in tenancy
allow group CloudGuard_ReadOnlyDetectors to read announcements in tenancy
allow group CloudGuard_ReadOnlyDetectors to read compartments in tenancy
allow group CloudGuard_ReadOnlyDetectors to read cloud-guard-config in tenancy
Allow a group to access Cloud Guard in a single compartment

Type of access: Read-only access to Cloud Guard in a single compartment. In the example policy, the group is "CloudGuard_ReadOnly_SingleCompartment" and the compartment name is "cgDemo_RestrictedAccess."

allow group CloudGuard_ReadOnly_SingleCompartment to read compartments in tenancy where target.compartment.name = 'cgDemo_RestrictedAccess'
allow group CloudGuard_ReadOnly_SingleCompartment to read cloud-guard-family in compartment cgDemo_RestrictedAccess
allow group CloudGuard_ReadOnly_SingleCompartment to read announcements in compartment cgDemo_RestrictedAccess
allow group CloudGuard_ReadOnly_SingleCompartment to read cloud-guard-config in tenancy
Allow a group to manage service connectors

Type of access: Ability to list, create, update, and delete service connectors  in the tenancy. Ability to move service connectors to different compartments in the tenancy.

Where to create the policy: In the tenancy.

Allow group A-Admins to manage serviceconnectors in tenancy
Allow a group to call Operations Insights ingest operations at tenancy

Type of access: Ability to call Operations Insights ingest operations at the tenancy level only.

Where to create the policy: In the tenancy.

allow group opsi-users to use opsi-database-insights in tenancy 
where any 
{request.operation='IngestSqlBucket', 
request.operation='IngestSqlText',
request.operation='IngestSqlPlanLines'}