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.

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 Autonomous Recovery Service admins manage protected databases, recovery service subnets, and protection policies
Type of access: Ability to manage Autonomous Recovery Service resources in all compartments:
  • Protected databases

  • Recovery service subnets

  • Protection policies

This policy is applicable if you want to allow a single set of Recovery Service admins to manage all Recovery Service resources 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 Recovery Service resources in a particular compartment, specify the required compartment instead of the tenancy.

Allow group RecoveryServiceGroup to manage recovery-service-family in tenancy
Let compliance admins manage protection policies

Type of access: Ability to manage protection policies in all compartments.

This policy is applicable if you want to allow a single set of compliance admins to manage Protection Policies 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 protection policies in a particular compartment, specify the required compartment instead of the tenancy.

Allow group ComplianceGroup to manage recovery-service-policy 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.

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

For policies used in connecting a DRG to VCNs and DRGs in other regions and tenancies, see IAM Policies for Routing Between VCNs.

Let network admins manage load balancers

Type of access: Ability to manage all components in Load Balancer. If the group needs to launch instances, see Let users launch compute instances.

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 wants to manage load balancers and network load balancers, additional policies to use the associated networking resources are required:

Allow group NetworkAdmins to manage load-balancers in tenancy

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

Allow group NetworkAdmins to manage instances 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 or detach volumes, you can delete the volume-family 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

To allow users to create new cloud networks and subnets, see Let network admins manage a cloud network.

To allow users to determine whether capacity is available for a specific shape before creating an instance, add the following statement to the policy:

Allow group InstanceLaunchers to manage compute-capacity-reports in tenancy
Let users launch compute instances from a specific custom image

Type of access: Ability to launch instances into the cloud network and subnets in compartment XYZ using only the specified custom image. The policy also includes the ability to attach/detach any existing volumes that already exist in compartment ABC. If the group doesn't need to attach/detach volumes, you can delete the volume-family statement.

To specify multiple custom images, you can use conditions.

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 ImageUsers to inspect instance-images in compartment ABC
Allow group ImageUsers to {INSTANCE_IMAGE_READ} in compartment ABC where target.image.id='<image_OCID>'
Allow group ImageUsers to manage instances in compartment ABC
Allow group ImageUsers to read app-catalog-listing in tenancy
Allow group ImageUsers to use volume-family in compartment ABC
Allow group ImageUsers to use virtual-network-family in compartment XYZ
Let image admins manage custom images

Type of access: Ability to do everything with custom images and compute instances. Also includes the ability to do everything with Object Storage buckets, objects, and namespaces in compartment Y (for creating images from objects and creating pre-authenticated requests to images); to attach/detach any existing volumes in compartment X; and to launch instances into the cloud network and subnets in compartment Z (for creating new instances to base an image on). If the group doesn't need to attach/detach volumes, you can delete the volume-family 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 (X, Y, and Z) to have control over the individual policy statements for their compartments, see Policy Attachment.

Allow group ImageAdmins to manage instances in compartment X
Allow group ImageAdmins to manage instance-images in compartment X
Allow group ImageAdmins to read app-catalog-listing in tenancy
Allow group ImageAdmins to manage object-family in compartment Y
Allow group ImageAdmins to use volume-family in compartment X
Allow group ImageAdmins to use virtual-network-family in compartment Z
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

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'

If the instance configuration used by the instance pool launches instances in a capacity reservation, add the following statement to the policy:

Allow service compute_management to use compute-capacity-reservations in tenancy

If the boot volume used in the instance configuration to create an instance pool is encrypted with a KMS key then, add the following statement to the policy

allow service compute, blockstorage, compute_management to use key-family in compartment <compartment_id/<tenant_id>>
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 users create Compute instance console connections

Type of access: Ability to create instance console connections.

Where to create the policy: In the tenancy.

Allow group <group_name> to manage instance-console-connection in tenancy
Allow group <group_name> to read instance in tenancy
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 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 or file system clone. 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 or file system clone.

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

Access limited to buckets with a specific defined tag: To limit access to the buckets with a specific tag in a given compartment, add the condition where target.bucket.tag.<TagNamespace>.<TagKeyDefinition>='<TagValue>'. The following policy allows the user to list all buckets in compartment ABC, however, they can only list the objects in and upload objects to the bucket with the tag MyTagNamespace.TagKey='MyTagValue':

Allow group ObjectWriters to read buckets in compartment ABC
Allow group ObjectWriters to manage objects in compartment ABC where all {target.bucket.tag.MyTagNamespace.TagKey='MyTagValue', 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'

Access limited to buckets with a specific defined tag

To limit access to the buckets with a specific tag in a given compartment, add the condition where target.bucket.tag.<TagNamespace>.<TagKeyDefinition>='<TagValue>'. The following policy allows the user to list all buckets in compartment ABC, however, they can only read the objects in and download the objects from the bucket with the tag MyTagNamespace.TagKey='MyTagValue':

Allow group ObjectReaders to read buckets in compartment ABC
Allow group ObjectReaders to read objects in compartment ABC where target.bucket.tag.MyTagNamespace.TagKey='MyTagValue'

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

Let users access customer data in Object Storage encrypted with customer-managed key

Type of access: Ability to create customer managed key. This consists of the ability to set up policies to access data encrypted with customer managed key.

allow group <group_in_tenancy> to manage vaults in compartment <key_located_compartment>
allow group <group_in_tenancy> to manage keys in compartment <key_located_compartment>
allow group <group_in_tenancy> to manage key-delegate in compartment <key_located_compartment>
allow group <group_in_tenancy> to use object-family in compartment <key_located_compartment>
allow service objectstorage-<region_name> to use keys in compartment <key_located_compartment>

The last statement in the above policy example is region specific. That means customers need to repeatedly write this statement for each region. To convenience policy setting, customers can use the following policy setting example:

allow group <group_in_tenancy> to manage vaults in compartment <key_located_compartment>
allow group <group_in_tenancy> to manage keys in compartment <key_located_compartment>
allow group <group_in_tenancy> to manage key-delegate in compartment <key_located_compartment>
allow group <group_in_tenancy> to use object-family in compartment <key_located_compartment>
allow any-user to use keys in compartment <key_located_compartment> where all {request.principal.type = 'service', request.service.name = /objectstorage-*/}
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 Database Service on Dedicated Infrastructure 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 Database Service on Cloud@Customer instances

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

Type of access:

Ability to do all things with MySQL Database and MySQL HeatWave resources in all compartments. Creating and managing MySQL Database DB Systems also requires limited access to VCNs, Subnets, and Tag namespaces in the tenancy.

Where to create the policy: In the tenancy, granting access to all compartments by policy inheritance.
Allow group <group_name> to {
  	COMPARTMENT_INSPECT, 
    VCN_READ, 
    SUBNET_READ, SUBNET_ATTACH, SUBNET_DETACH, 
    NETWORK_SECURITY_GROUP_UPDATE_MEMBERS,
    VNIC_CREATE, VNIC_UPDATE, VNIC_DELETE, VNIC_ASSOCIATE_NETWORK_SECURITY_GROUP
  } in tenancy | compartment <compartment_name> | compartment <compartment_ocid>
  Allow group <group_name> to manage mysql-family in tenancy | compartment <compartment_name> | compartment <compartment_ocid>
  Allow group <group_name> to use tag-namespaces in tenancy
Let database admins manage Oracle Cloud external database resources
Type of access: Ability to do all things with the following OCI external database resources in all compartments:
  • OCI external container database resources
  • OCI external pluggable database resources
  • OCI external non-container database resources
  • OCI external database connectors

This makes sense if you want to have a single set of database admins manage all the OCI external database resources 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 OCI external database resources in a particular compartment, specify that compartment instead of the tenancy.

Allow group OnPremDatabaseAdmins to manage external-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 User Roles Associated with Autonomous Database on Dedicated Exadata Infrastructure. Enables Autonomous Database fleet administrator access to the any workload types, and to manage the following dedicated Exadata infrastructure resources: Autonomous Container Databases and Autonomous VM Clusters.

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

The autonomous-database-family aggregate resource-type does not cover the cloud-exadata-infrastructures resource-type needed to provision Autonomous Database on dedicated Exadata infrastructure. See Policy Details for Exadata Database Service on Dedicated Infrastructure for information on the cloud Exadata infrastructure permissions. See Let database admins manage Oracle Cloud database systems for a sample policy covering cloud Exadata infrastructure resources.

If you must restrict access to the Autonomous VM Cluster and Autonomous Container Database resource types (applicable only to dedicated Exadata infrastructure), 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 Autonomous Database on Dedicated Exadata Infrastructure. Enables Autonomous Database database administrators access to databases and backups of the various workload types, but denies access to Autonomous Container Databases, Autonomous VM Clusters, and Cloud Exadata Infrastructure resources.

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 for databases and backups to either the a specific workload type, use a where clause.

Example 3: For Autonomous Database on Dedicated Exadata Infrastructure. Limits Autonomous Database access to databases and backups for a specific workload type.

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

In the preceding code examples, workload_type is one of the strings listed in the following table.

Autonomous Database Workload Type Strings
Database Workload Type workload_type String for Policies
Autonomous Database for Transaction Processing and Mixed Workloads OLTP
Autonomous Database for Analytics and Data Warehousing DW
Autonomous JSON Database AJD
Oracle APEX Application Development APEX
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. To reduce the scope of access to just vaults, keys, or secret components, include only the policy statement that pertains to the respective individual or aggregate resource-type, as appropriate.

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>, <file_storage_service_user>, 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.

The name of the File Storage service user depends on your realm . For realms with realm key numbers of 10 or less, the pattern for the File Storage service user is FssOc<n>Prod, where n is the realm key number. Realms with a realm key number greater than 10 have a service user of fssocprod. For more information about realms, see About Regions and Availability Domains.

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 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 admins manage streaming resources

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 stream-family 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 publish messages to a stream in a specific stream pool

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.streampool.id = '<streampool_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 list metric definitions in a compartment

Type of access: Ability to list metric definitions  in a specific compartment. For more information, see Listing Metric Definitions.

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 <group_name> to inspect metrics in compartment <compartment_name>
Let users query metrics in a compartment

Type of access: Ability to query metrics  for supported resources in a specific compartment. For more information, see Creating a Query.

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 <group_name> to read metrics in compartment <compartment_name>
Restrict queries to a specific metric namespace

Type of access: Ability to query metrics  for resources under a specific metric namespace . For more information, see Creating a Query.

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 <group_name> to read metrics in compartment <compartment_name>
  where target.metrics.namespace='<metric_namespace>'
Let users publish custom metrics

Type of access: Ability to publish custom metrics  under a specific metric namespace  to the Monitoring service, as well as view metric data, create alarms and topics, and use streams with alarms. For more information about publishing custom metrics, 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.

Note

To limit the group to the permissions required for selecting streams, replace use streams with {STREAM_READ, STREAM_PRODUCE}.
Allow group <group_name> to use metrics in tenancy 
  where target.metrics.namespace=<metric_namespace>'
Allow group <group_name> to read metrics in tenancy
Allow group <group_name> to manage alarms in tenancy
Allow group <group_name> to manage ons-topics in tenancy
Allow group <group_name> to use streams in 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 about compute instances calling APIs, see Calling Services from an Instance.

Where to create the policy: In the tenancy.

Allow dynamic-group MetricInstances to read metrics in tenancy
Let users view alarms

Type of access: Ability to get alarm details and get alarm history. Does not include the ability to create alarms or to create or delete topics.

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, the group 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 <group_name> to read alarms in tenancy
Allow group <group_name> to read metrics in tenancy
Let users manage alarms

Type of access: Ability to manage alarms, using streams and existing topics for notifications. Does not include the ability to create or delete topics.

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, the group 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 <group_name> to manage alarms in tenancy
Allow group <group_name> to read metrics in tenancy
Allow group <group_name> to use ons-topics in tenancy
Allow group <group_name> to use streams in tenancy
Let users manage alarms and create topics

Type of access: Ability to manage alarms, including creating topics (and subscriptions) for notifications (and using streams for notifications).

Where to create the policy: In the tenancy. Because of the concept of policy inheritance, the group 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 <group_name> to manage alarms in tenancy
Allow group <group_name> to read metrics in tenancy
Allow group <group_name> to manage ons-topics in tenancy
Allow group <group_name> to use streams 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 Accessing Cost and Usage Reports.

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 Expenses 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 and subscriptions

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 TopicManagers to manage ons-topics in tenancy
Allow a group to manage 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 SubscriptionUsers 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 TopicUsers to use ons-topics in tenancy
Let users create, deploy, and manage functions and applications using Cloud Shell

Type of access: Ability to create, deploy, and manage OCI Functions applications and functions using Cloud Shell. These policy statements give the group access to Cloud Shell, repositories in Oracle Cloud Infrastructure Registry, logs, metrics, functions, networks, and tracing.

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 resources in a particular compartment, you can specify the compartment instead of the tenancy for most policy statements. However, to use cloud-shell, to manage repos, and to read objectstorage-namespaces must always be scoped to the tenancy.


Allow group functions-developers to use cloud-shell in tenancy
Allow group functions-developers to manage repos in tenancy
Allow group functions-developers to read objectstorage-namespaces in tenancy
Allow group functions-developers to manage logging-family in tenancy
Allow group functions-developers to read metrics in tenancy
Allow group functions-developers to manage functions-family in tenancy
Allow group functions-developers to use virtual-network-family in tenancy
Allow group functions-developers to use apm-domains in tenancy
Allow group functions-developers to read vaults in tenancy
Allow group functions-developers to use keys in tenancy
Allow service faas to use apm-domains in tenancy
Allow service faas to read repos in tenancy where request.operation='ListContainerImageSignatures'
Allow service faas to {KEY_READ} in tenancy where request.operation='GetKeyVersion'
Allow service faas to {KEY_VERIFY} in tenancy where request.operation='Verify'
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 administer all aspects of Full Stack Disaster Recovery operations in the entire tenancy

Type of access: Ability to allow a group to be superusers for all Full Stack Disaster Recovery operations.

Where to create the policy: In the tenancy
Allow group DRUberAdmins to manage disaster-recovery-family in tenancy
Allow a group to create Full Stack Disaster Recovery configurations and execute Prechecks

Type of access: Ability to allow a group to create Disaster Recovery (DR) protection groups, DR plans, and execute Prechecks but not actually create DR plan executions.

Where to create the policy: In the compartment.

Allow group DRMonitors to manage disaster-recovery-protection-groups in compartment ApplicationERP
Allow group DRMonitors to manage disaster-recovery-plans in compartment ApplicationERP
Allow group DRMonitors to manage disaster-recovery-prechecks in compartment ApplicationERP
Allow a group of users to create Full Stack Disaster Recovery configurations in a specific compartment

Type of access: Ability to allow a group to create Disaster Recovery (DR) protection groups and DR plans but not create any DR plan executions or Prechecks.

Where to create the policy: In the compartment.
Allow group DRConfig to manage disaster-recovery-protection-groups in compartment ApplicationERP
Allow group DRConfig to manage disaster-recovery-plans in compartment ApplicationERP
Allow Object Storage to use Keys in Vault

Type of access: Other services to integrate with KMS to use KMS keys.

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.

Example: Allow service blockstorage to use keys in compartment ABC where target.key.id = '<key_OCID>'

allow service blockstorage to use keys in compartment Compartments where target.key.id = ocid1.key.oc1........
Let security admins manage all bastions and sessions

Type of access: Ability to manage all resources in the Bastion service in all compartments. This makes sense if you want to have a single set of security admins manage all bastions  and sessions  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 bastions and bastion sessions in a particular compartment, specify that compartment instead of the tenancy.

Allow group SecurityAdmins to manage bastion in tenancy
Allow group SecurityAdmins to manage bastion-session in tenancy
Allow group SecurityAdmins to manage virtual-network-family in tenancy
Allow group SecurityAdmins to read instance-family in tenancy
Allow group SecurityAdmins to read instance-agent-plugins in tenancy
Allow group SecurityAdmins to inspect work-requests in tenancy
Let security admins manage bastion sessions

Type of access: Ability to manage all sessions  on all bastions  and in all compartments, including creating, connecting to, and terminating sessions.

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

Allow group SecurityAdmins to use bastion in tenancy
Allow group SecurityAdmins to manage bastion-session in tenancy
Allow group SecurityAdmins to manage virtual-network-family in tenancy
Allow group SecurityAdmins to read instance-family in tenancy
Allow group SecurityAdmins to read instance-agent-plugins in tenancy
Allow group SecurityAdmins to inspect work-requests in tenancy
Let security admins manage bastion sessions for a specific target host in a compartment

Type of access: Ability to manage sessions  on a bastion  in a specific compartment, and only for sessions that provide connectivity to a specific Compute instance.

Where to create the policy: In the tenancy, so that access is easily granted to all compartments by way of policy inheritance.

Allow group SecurityAdmins to use bastion in compartment ABC
Allow group SecurityAdmins to manage bastion-session in compartment ABC where ALL {target.resource.ocid='<instance_OCID>', target.bastion-session.username='<session_username>'}
Allow group SecurityAdmins to manage virtual-network-family in tenancy
Allow group SecurityAdmins to read instance-family in tenancy
Allow group SecurityAdmins to read instance-agent-plugins in tenancy
Allow group SecurityAdmins to inspect work-requests in tenancy
Let security admins configure scanning of instances in all compartments

Type of access: Ability to configure Oracle Cloud Infrastructure Vulnerability Scanning Service to scan all Compute instances  in all compartments, and to view the scanning results. Consider this policy if you want to have a single set of security administrators configure vulnerability scanning for all instances.

Where to create the policy: In the tenancy, which grants access to all compartments by way of policy inheritance. To reduce the scope of access to just the Compute instances in a particular compartment, specify that compartment instead of the tenancy.

Allow group SecurityAdmins to manage vss-family in tenancy
Allow service vulnerability-scanning-service to manage instances in tenancy
Allow service vulnerability-scanning-service to read compartments in tenancy
Allow service vulnerability-scanning-service to read vnics in tenancy
Allow service vulnerability-scanning-service to read vnic-attachments in tenancy
Let users view vulnerability scan results in all compartments

Type of access: Ability to view the results of scanning Compute instances  in all compartments for security vulnerabilities. Consider this policy if you have a dedicated team responsible for reviewing or auditing the security of your entire tenancy.

Where to create the policy: In the tenancy, which grants access to all compartments by way of policy inheritance. To reduce the scope of access to just the scanning results in a particular compartment, specify that compartment instead of the tenancy.

Allow group SecurityReviewers to read vss-family in tenancy
Allow a group to manage connectors

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

Where to create the policy: In the tenancy.

Allow group A-Admins to manage serviceconnectors in tenancy

See also IAM Policies (Securing Connector Hub).

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'}
Let users create and delete workspaces without networking (Data Integration)

Ability to create, delete, and modify workspaces within a compartment.

allow group <group-name> to manage dis-workspaces in <compartment-name>
allow group <group-name> to manage dis-work-requests in <compartment-name>
allow group <group-name> to manage tag-namespaces in <compartment-name>
Let users create and delete workspaces with networking (Data Integration)

Ability to create, delete, and modify workspaces within a virtual network.

allow service dataintegration to use virtual-network-family in <compartment-name>
allow group <group-name> to manage dis-workspaces in <compartment-name>
allow group <group-name> to manage dis-work-requests in <compartment-name>
allow group <group-name> to use virtual-network-family in <compartment-name>
allow group <group-name> to manage tag-namespaces in <compartment-name>
Let users and resource principal access and use Object Storage for a given workspace (Data Integration)

Ability to create and use Object Storage data assets within all workspaces.

allow any-user to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace'}
allow any-user to manage objects in <compartment-name> where ALL {request.principal.type='disworkspace'}
allow group <group-name> to use object-family in <compartment-name>

To give access to an individual workspace, specify the OCID for the workspace where you want to allow access. For example:

allow any-user to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
allow any-user to manage objects in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
Let users and resource principal access and use autonomous databases as a target for a given workspace (Data Integration)

Ability to create and use autonomous database data assets within all workspaces.

allow any-user to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace'}
allow any-user to manage objects in <compartment-name> where ALL {request.principal.type='disworkspace'}
allow group <group-name> to use object-family in <compartment-name>
allow any-user to manage buckets in <compartment-name> where ALL {request.principal.type='disworkspace', request.permission='PAR_MANAGE'}

To give access to an individual workspace, specify the OCID for the workspace where you want to allow access. For example:

allow any-user to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
allow any-user to manage objects in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
allow any-user to manage buckets in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>', request.permission='PAR_MANAGE'}
Let users move workspaces to a new compartment (Data Integration)

Ability to move workspaces to a new compartment.

allow service dataintegration to inspect compartments in <compartment-name>
allow group <group-name> to manage dis-workspaces in <compartment-name>
Let users publish tasks to the OCI Data Flow service (Data Integration)

Ability to publish the different tasks within all workspaces to the OCI Data Flow service.

allow any-user to manage dataflow-application in <compartment-name> where ALL {request.principal.type='disworkspace'}

To give access to an individual workspace, specify the OCID for the workspace where you want to allow access. For example:

allow any-user to manage dataflow-application in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
Let users access the OCI Vault service for a given workspace (Data Integration)

Ability to use OCI Vault secrets within all workspaces.

allow any-user to read secret-bundles in <compartment-name> where ALL {request.principal.type='disworkspace'}
allow group <group-name> to read secret-bundles in <compartment-name>

To give access to an individual workspace, specify the OCID for the workspace where you want to allow access. For example:

allow any-user to read secret-bundles in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
Let admins manage announcement subscriptions

Type of access: Ability to manage subscriptions that deliver announcements about the operational status of Oracle Cloud Infrastructure services.

Where to create the policy: The easiest approach is to put this policy in the tenancy. Because of the concept of policy inheritance, the group that you grant access can then manage announcement subscriptions in any compartment. To reduce the scope of access to announcements for a particular compartment, specify the compartment instead of the tenancy.

Allow group AnnouncementAdmins to manage announcement-subscriptions in tenancy

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