Policy Examples

Use the following examples to learn about Data Integration IAM policies.

The overall syntax of a policy statement is:

allow <subject> to <verb> <resource-type> in <location> where <condition>

For a description of each variable, see Policy Syntax.

Note

After you add IAM components (for example, dynamic groups and policy statements), don't try to perform the associated tasks immediately. New IAM policies require about five to 10 minutes to take effect.

To export and import objects, see Enable Export and Import of Workspace and Objects in Workspace.

Review also this Policies blog to help identify the right policies for your needs.

Policy Examples to Enable Access to Data Integration and Use Workspaces

To use Data Integration workspaces, you need to create policies.

Enable Use of Private Network in Workspaces

To use private network connections to your data sources, you must give Data Integration permission to manage the virtual networks that you have set up for integration.

Without the following policy, data integration fails.

allow service dataintegration to use virtual-network-family in compartment <compartment-name>

To give permission to a group to manage networking resources in a compartment:

allow group <group-name> to manage virtual-network-family in compartment <compartment-name>

For non-admin users:

allow group <group-name> to use virtual-network-family in compartment <compartment-name>

allow group <group-name> to inspect instance-family in compartment <compartment-name>

Enable Access to List Users and Compartments

To give Data Integration permission to list users and compartments, you can use inspect.

allow service dataintegration to inspect users in tenancy

allow group <group-name> to inspect compartments in compartment <target-compartment-name>

Enable Access to View Workspaces

To allow a group to simply view the list of all Data Integration workspaces, you can use inspect.

To view workspaces in a specific compartment:

allow group <group-name> to inspect dis-workspaces in compartment <compartment-name>

Enable Access to Get Workspace Details

To allow a group to simply view the list of all Data Integration workspaces, you can use inspect.

The verb, read, for dis-workspaces includes the same permissions and API operations as inspect, plus the permission, DIS_WORKSPACE_READ, and the API operations that it covers.

To allow a group to list and get details for dis-workspaces in a specific compartment, you can use the verb, read:

allow group <group-name> to read dis-workspaces in compartment <compartment-name>

To allow a group to list and get details for dis-workspaces and the objects it contains in the tenancy, you can use:

allow group <group-name> to read dis-workspaces in tenancy

Enable Access to Update Workspaces

To allow a group to update workspaces and the objects they contain, you can use the verb, use.

The verb, use, for dis-workspaces includes the same permissions and API operations as read and inspect, plus the permission, DIS_WORKSPACE_UPDATE, and the API operations that it covers.

To allow a group to update dis-workspaces in a specific compartment, you can use:

allow group <group-name> to use dis-workspaces in compartment <compartment-name>

To allow a group to update dis-workspaces and the objects it contains in the tenancy, you can use:

allow group <group-name> to use dis-workspaces in tenancy

To allow a group to update a specific workspace and not any other workspace:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

To allow a group to update a set of specified workspaces:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')

Note

You can copy your workspace OCID from the Console.

Enable Access to Manage Workspaces

To allow a group to manage workspaces and the objects they contain, you can use the verb, manage.

The verb, manage, for dis-workspaces includes the same permissions and API operations as inspect, read, and useplus the permissions, DIS_WORKSPACE_CREATE and DIS_WORKSPACE_DELETE, and the API operations that it covers.

To allow a group to manage dis-workspaces in a specific compartment, you can use :

allow group <group-name> to manage dis-workspaces in compartment <compartment-name>

To allow a group to manage dis-workspaces and the objects it contains in the tenancy, you can use:

allow group <group-name> to manage dis-workspaces in tenancy

To allow a group to manage a specific workspace and not any other workspace:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

To allow a group to manage a set of specified workspaces:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')

Note

You can copy your workspace OCID from the Console.

Allow Searching in Workspaces

To allow Data Integration to search within workspaces in your tenancy, define the following policies in the root compartment of your tenancy.

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

Allow Exporting and Importing of Objects in Workspaces

Data Integration needs specific policies to use export and import. See Required Setup and Policies in the Export and Import of Objects topic.

Data Integration also needs to access resources in Object Storage for export and import. See Policy Examples to Enable Access to OCI Object Storage.

Policy Examples to Set Up Cross-Tenancy Access for Project Copy and Application Copy

To create an application or a project in a tenancy (target) by copying resources from an existing application or project that's in a different tenancy (source), certain policies must be set up in the source and target tenancies.

You need to have the following to write cross-tenancy policy statements:

The target tenancy name and OCID
The source tenancy name and OCID
The user group OCID of a group whose users have read and write permissions on the source and target workspaces

In the target tenancy:

The target tenancy is where the new application or project copy is to be created.

Create a user group and add users to the group.

Define a policy with the following statements:

define tenancy <source-tenancy-name> as <source-tenancy-OCID>

endorse group <group-name> to manage dis-family in tenancy <source-tenancy-name>

endorse group <group-name> to manage dis-workspaces in tenancy <source-tenancy-name>

endorse group <group-name> to read compartments in tenancy <source-tenancy-name>

endorse any-user to read compartments in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}

endorse any-user to manage dis-workspaces in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}

In the source tenancy:

The source tenancy has the workspace with the existing application or project that's to be copied.

Define a policy with the following statements:

define tenancy <target-tenancy-name> as <target-tenancy-OCID>

define group <group-name> as <group-OCID>

For generic access to all workspaces:

admit group <group-name> of tenancy <target-tenancy-name> to read compartments in tenancy

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy

admit any-user of tenancy <target-tenancy-name> to read compartments in tenancy  where ALL {request.principal.type = 'disworkspace'}

admit any-user of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where ALL {request.principal.type = 'disworkspace'}

Instead of generic access, you can provide a more fine-grained permission that's based on the source workspace OCID or source application key:

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.workspace.id  = '<source-tenancy-workspace-OCID>'

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.application.key = '<source-existing-application-key>'

Policy Permission and API Examples

Here are some examples using permissions in a condition:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_READ'

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_UPDATE'

Here are some examples to using API operations in a condition:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'GetWorkspace'

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'UpdateWorkspace'

Note

A permission can have more than one API related to it. If you use a permission and not a specific API in a policy, check Permissions Required for Each API Operation to ensure that your policy covers the APIs that you intend.

Policy Examples with Conditional Statements

Note

You can copy your workspace OCID from the Console.

You use variables when adding conditions to a policy. See General Variables for Requests.

Policies with conditional statements have a where clause. For example, to allow a group to update a specific workspace and not any other workspace:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

To allow only the group who creates a workspace to use it:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.createdBy = request.user.id

To allow a group to manage all Data Integration resources, except for deleting workspaces:

allow group <group-name> to manage dis-family in compartment <compartment-name> where request.permission != 'DIS_WORKSPACE_DELETE'

Policy statements that use a key in a where clause allow users in a group to use workspaces in a compartment where the request has that specific key. For example, you can allow a group to operate only in a specific application.

To restrict a group to only execute tasks in an application:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.application.key='<application-key>'}

To allow a group to create objects (such as tasks and data flows) only in a folder:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.folder.key='<folder-key>'}

To allow a group to update or delete a specific object such as a data flow:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.object.key='<object-key>'}

Policy Examples to Enable Access to OCI Object Storage

Data Integration needs specific permission to Oracle Cloud Infrastructure Object Storage to access metadata, and read and write data.

To create an Object Storage data asset and browse its schemas, you must belong to a user group that has permission to read Object Storage. See On Behalf Of Policy Examples.

To test a the Object Storage connection, ensure that your Data Integration workspace or compartment has, at minimum, READ access to objectstorage-namespaces. See Resource Principal Policy Examples.

To create and execute a data flow using Object Storage as a source or target, your workspace or compartment must have all policies mentioned in Resource Principal Policy Examples.

Note

The WHERE clause content is optional but required to limit the resources that access Oracle Cloud Infrastructure Object Storage. You can use it to fine tune access according to your needs. To apply a policy statement to:

All workspaces, use WHERE ALL {request.principal.type='disworkspace'}
A specific workspace, use WHERE ALL {request.principal.id='<workspace-OCID>'}
You can copy your workspace OCID from the Console.
All workspaces in a specific compartment, use WHERE ALL {request.resource.compartment.id = '<compartment-OCID>'}

For complete details about writing policies to control access to Object Storage, see Details for Object Storage.

Resource Principal Policy

These policies allow a Data Integration workspace or its compartment to validate connections to Oracle Cloud Infrastructure Object Storage, and read and write data.

The policies differ slightly when the Data Integration workspace and Object Storage data asset belong to the same tenancy versus when they are in different tenancies.

Within the same tenancy

If your Data Integration workspace and Object Storage data source are in the same tenancy, then you must create the following policies:

allow any-user to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.operation = 'GetBucket'}

allow any-user to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

Within different tenancies

If your Data Integration workspace and Object Storage data source are in different tenancies, then you must create the following policies:

In the workspace tenancy:


Endorse any-user to read buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}


Endorse any-user to manage objects in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}


Endorse any-user to manage buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}


Endorse any-user to inspect compartments in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace'}

In the Object Storage tenancy:

Admit any-user of tenancy <tenancy-name> to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}


Admit any-user of tenancy <tenancy-name> to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}


Admit any-user of tenancy <tenancy-name> to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}


Admit any-user of tenancy <tenancy-name> to inspect compartments in tenancy

On Behalf Of Policy Examples

These policies allow the logged-in user to list and browse compartments, Object Storage buckets, and objects based on the permissions already assigned to the user.

The policies differ slightly when the Data Integration workspace and Object Storage data asset belong to the same tenancy versus when they are in different tenancies.

Within the same tenancy

If the Data Integration workspace and Object Storage data asset belong to the same tenancy, then the user (or the group the user belongs to) must have access to Object Storage:

allow group <group-name> to use object-family in compartment <compartment-name>

Within different tenancies

If your Data Integration workspace and Object Storage data asset are in different tenancies, then you must create the following policies:

In the workspace tenancy:

Define tenancy <any-name1> as <object-storage-tenancy-OCID>

Endorse group <group-name> to inspect compartments in tenancy <any-name1>

Endorse group <group-name> to use object-family in tenancy <any-name1>

In the Object Storage tenancy:

Define tenancy <any-name2> as <workspace-tenancy-OCID>

Define group <workspace-tenancy-group-name> as <workspace-tenancy-group-OCID>

Admit group <group-name> of tenancy <any-name2> to inspect compartments in tenancy

Admit group <group-name> of tenancy <any-name2> to use object-family in compartment <compartment-name>

Policy Examples to Use Autonomous Databases as Targets

When you use Autonomous Data Warehouse or Autonomous Transaction Processing databases as a target database in Data Integration, OCI Object Storage is used for staging data and completing the operations. To allow pre-authentication for such requests, you need the following policy.

allow any-user to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.permission = 'PAR_MANAGE'}

While working with autonomous databases in Data Integration, Object Storage is also used. So, you must create all the required Object Storage policies.

Policy Examples for Publishing to the OCI Data Flow Service

Before you can publish tasks from OCI Data Integration to the OCI Data Flow service with private endpoints, ensure that you have the following policies.

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

allow any-user to manage dataflow-run in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

allow group <group-name> to read dataflow-application in compartment <compartment-name>

allow group <group-name> to manage dataflow-run in compartment <compartment-name>

allow any-user to read dataflow-private-endpoint in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

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

For non-administrator users, these policies are required:

allow group <group-name> to inspect dataflow-private-endpoint in compartment <compartment-name>

allow group <group-name> to read secret-bundles in compartment <compartment-name>

Policy Examples to Access OCI AI Service REST Endpoint

To authenticate running a REST task using the application resource principal, add the following to obtain the OCI resource principal.

allow any-user to use ai-service-language-family in tenancy where ALL {request.principal.type = 'disapplication', request.principal.id = '<disapplication-ocid>'}

Oracle Cloud Infrastructure Documentation

Policy Examples

Within the same tenancy

Within different tenancies

Within the same tenancy

Within different tenancies