Common Policies

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

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

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

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
    

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.

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

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

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

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

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

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

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

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

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

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

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'

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.

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.

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

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

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

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

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

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.

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

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.

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.

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-group to use keys in compartment <key_located_compartment> where all {request.principal.type = 'service', request.service.name = /objectstorage-*/}

Type of access: Ability of a group of users to do all actions to an Object Storage bucket and its objects.

Where to create the policy: In the tenancy where the users reside.

ALLOW group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'prod/*'} 

Type of access: Ability of a group of users to have read-only access to an Object Storage bucket and its objects.

Where to create the policy: In the tenancy where the users reside.

ALLOW group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'prod/*', any{request.permission='OBJECT_INSPECT', request.permission='OBJECT_READ'}}

Type of access: Ability of a group of users to have write-only access to a folder of objects within a bucket Users can't view a list of objects in the bucket, nor delete any objects it contains.

Where to create the policy: In the tenancy where the users reside.

ALLOW group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'prod/*', any{request.permission='OBJECT_CREATE'}}

Type of access: Ability of a group of users to have read and write access to a folder of objects within an Object Storage bucket. Users can't generate a list of objects in the folder, nor overwrite any existing objects in the folder.

Where to create the policy: In the tenancy where the users reside.

ALLOW group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'prod/*', any{request.permission='OBJECT_CREATE', request.permission='OBJECT_READ'}}

Type of access: Ability of a specified user to have full access to all objects that match a specified pattern within an Object Storage bucket.

Where to create the policy: In the tenancy where the user resides.

ALLOW any-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = '*.pdf', request.user.id='ocid1.user.oc1..exampleuniqueID'}

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

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

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.

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

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

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.

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

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

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

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, Kubernetes Engine, 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, Kubernetes Engine, 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>'

Type of access: Ability to associate a Block Volume volume with a specific key authorized for use in a specific compartment. With this policy, a user in the dynamic group doesn't have permission to use the key itself. Rather, by association, the key can be used by Block Volume on behalf of the user to create or update an encrypted volume, and to encrypt or decrypt data in the volume.

This policy requires that you also have a companion policy that lets Block Volume 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 dynamic group VolumeWriters to use key-delegate in compartment ABC where target.key.id = '<key_OCID>'

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, Kubernetes Engine, 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>, 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 Kubernetes Engine, the service name used in the policy is oke.

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

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

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

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

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

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).

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.

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.

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

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

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

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

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

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>

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>

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

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.

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

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

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

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

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

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

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

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

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

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

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'

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.

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

Where to create the policy: In the tenancy.

allow group <RuleAdmins> to inspect compartments in tenancy

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

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

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

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

allow group <RuleAdmins> to manage cloudevents-rules in tenancy

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

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

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

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

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

Allow group DRUberAdmins to manage disaster-recovery-family in tenancy

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

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.

Allow group DRConfig to manage disaster-recovery-protection-groups in compartment ApplicationERP
Allow group DRConfig to manage disaster-recovery-plans in compartment ApplicationERP

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 objectstorage-<region> to use keys in compartment ABC where target.key.id = '<key_OCID>'

allow service objectstorage-<region> to use keys in compartment Compartments where target.key.id = ocid1.key.oc1..exampleuniqueID

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

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

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

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

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

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).

Type of access: Ability to call Ops 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'}

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>

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>

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

allow any-group to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace'}
allow any-group 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-group to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
allow any-group to manage objects in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}

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

allow any-group to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace'}
allow any-group 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-group 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-group to use buckets in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
allow any-group to manage objects in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}
allow any-group to manage buckets in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>', request.permission='PAR_MANAGE'}

Ability to search the components of Data Integration in a given workspace.

This policy must be applied at the tenancy (root compartment) level.

allow service dataintegration to {TENANCY_INSPECT} in tenancy
allow service dataintegration to {DIS_METADATA_INSPECT} in tenancy

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>

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

allow any-group 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-group to manage dataflow-application in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}

Ability to use OCI Vault secrets within all workspaces.

allow any-group 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-group to read secret-bundles in <compartment-name> where ALL {request.principal.type='disworkspace', request.principal.id='<workspace-ocid>'}

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.