Oracle Cloud Infrastructure Documentation

Data Integration Policies

You use the Oracle Cloud Infrastructure Identity and Access Management (IAM) service to create policies.

By default, only the users in the Administrators group can access all resources and functions in Data Integration. To control non-administrator user access to Data Integration resources and functions, you create IAM groups and then write policies that give the groups proper access.

For a complete list of Oracle Cloud Infrastructure policies, see Policy Reference.

Overview of Policy Syntax

The overall syntax of a policy statement is:

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

For example, you can specify:

  • A group or dynamic group by name or OCID as the <subject>. Or, you can use any-user to cover all users in the tenancy.

  • inspect, read, use, and manage as the <verb> to give a <subject> access to one or more permissions.

    As you go from inspect > read > use > manage, the level of access generally increases, and the permissions granted are cumulative. For example, use includes read plus the ability to update.

  • A family of resources such as virtual-network-family for the resource-type. Or, you can specify an individual resource in a family such as vcns and subnets.

  • A compartment by name or OCID as the <location>. Or, you can use tenancy to cover the entire tenancy.

  • One or more conditions in <condition>, which must be met for access to be granted. For multiple conditions, you can use any or all.

    A condition consists of one or more variables. A variable can be relevant to the request itself (for example, request.operation) or to the resource being acted upon in the request (for example, target.workspace.id). To illustrate, 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>'

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

For complete details, see Policy Syntax. For more information about creating policies, see How Policies Work and Policy Reference.

Resource-Types

Data Integration offers both aggregate and individual resource-types for writing policies.

You can use aggregate resource-types to write fewer policies. For example, instead of allowing a group to manage dis-workspaces and dis-work-requests, you can write a policy that allows the group to manage the aggregate resource-type, dis-family.

Aggregate Resource-Type Individual Resource-Types
dis-family

dis-workspaces

dis-work-requests
The APIs covered for the aggregate dis-family resource-type cover the APIs for dis-workspaces and dis-work-requests. For example, 
allow group dis-admins to manage dis-family in compartment <compartment_name>
is the same as writing the following two policies:
allow group dis-admins to manage dis-workspaces in compartment <compartment_name>
allow group dis-admins to manage dis-work-requests in compartment <compartment_name>

Supported Variables

To add conditions to your policies, you can use either Oracle Cloud Infrastructure general or service specific variables.

Data Integration supports all the general variables (see General Variables for All Requests), plus additional ones listed here:

Operations for This Resource Type...Can Use These Variables...Variable TypeComments
dis-workspacetarget.workspace.idEntity (OCID)Not available to use with CreateWorkspace

Operations for This API Path...Can Use These Variables...Variable TypeComments
/workspaces/{workspaceId}/applications/{applicationKey}/*target.application.keyEntity (Key)Not available to use with ListApplications, CreateApplication
/workspaces/{workspaceId}/applications

source.workspace.id

source.application.key

 Entity (Key)

Only available to use with CreateApplication.

Not available to use with ListApplications, GetApplication, UpdateApplication, or DeleteApplication.
/workspaces/{workspaceId}/projects/{projectKey}/*target.object.keyEntity (Key)
/workspaces/{workspaceId}/folders/{folderKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateFolder
/workspaces/{workspaceId}/dataflows/{dataflowKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateDataflow, UpdateDataflow
/workspaces/{workspaceId}/tasks/{dataflowKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateTask, UpdateTask
/workspaces/{workspaceId}/dataAssets/{dataAssetKey}/*target.object.keyEntity (Key)
/workspaces/{workspaceId}/connections/{connectionKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateConnection, UpdateConnection
/workspaces/{workspaceId}/pipelines/{pipelineKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreatePipeline, UpdatePipeline

Details for Verbs + Resource-Type Combinations

There are various Oracle Cloud Infrastructure verbs and resource-types that you can use to create a policy.

The following tables show the permissions and API operations covered by each verb for Data Integration. The level of access is cumulative as you go from inspect to read to use to manage. A plus sign (+) in a table cell indicates incremental access compared to the cell directly above it, whereas "no extra" indicates no incremental access.

dis-work-requests
Permission APIs Fully Covered

INSPECT
DIS_WORK_REQUEST_INSPECT ListWorkRequests
ListWorkRequestErrors
ListWorkRequestLogs

READ

INSPECT +

INSPECT +
DIS_WORK_REQUEST_READ GetWorkRequest

USE
no extra no extra

MANAGE
no extra no extra
Note

Each permission for dis-work-requests fully covers one or more APIs. There are no partially covered APIs for dis-work-requests permissions.
dis-workspaces
Permission APIs Fully Covered

INSPECT
DIS_WORKSPACE_INSPECT ListWorkspaces
DIS_WORKSPACE_OBJECT_INSPECT ListProjects
ListFolders
ListDataFlows
ListTasks
ListTaskValidations
ListApplications
ListPublishedObjects
ListDependentObjects
ListTaskRuns
ListTaskRunLogs
ListDataAssets
ListConnections
ListSchemas
ListDataEntities
ListConnectionValidation
ListDataFlowValidations
ListExternalPublications
ListExternalPublicationValidations
ListReferences
ListPatchChanges
ListPipelines
ListSchedules
ListTaskSchedules
READ

INSPECT +

INSPECT +
DIS_WORKSPACE_READ GetWorkspace
DIS_WORKSPACE_OBJECT_READ GetCountStatistic
GetProject
GetFolder
GetDataFlow
GetTask
GetTaskValidation
GetApplication
GetPatch
GetPublishedObject
GetDependentObject
GetTaskRun
GetDataAsset
GetConnection
GetSchema
GetDataEntity
GetConnectionValidation
GetDataFlowValidation
GetExternalPublication
GetExternalPublicationValidation
GetReference
GetPipeline
GetSchedule
GetTaskSchedule

USE

READ +

READ +
DIS_WORKSPACE_EXECUTE ExecuteTask
DIS_WORKSPACE_UPDATE UpdateWorkspace
DIS_WORKSPACE_OBJECT_EXECUTE CreateTaskRun
UpdateTaskRun
DIS_WORKSPACE_OBJECT_UPDATE UpdateProject
UpdateFolder
UpdateDataFlow
UpdateTask
UpdateApplication
UpdateDataAsset
UpdateConnection
UpdateReference
UpdateExternalPublication
UpdatePipeline
UpdateSchedule
UpdateTaskSchedule
DIS_WORKSPACE_OBJECT_CREATE CreateProject
CreateFolder
CreateDataFlow
CreateTask
CreateTaskValidation
CreatePatch
CreateApplication
CreateDataAsset
CreateConnection
CreateEntityShape
CreateConnectionValidation
CreateDataFlowValidation
CreateExternalPublication
CreateExternalPublicationValidation
CreatePipeline
CreateSchedule
CreateTaskSchedule
DIS_WORKSPACE_OBJECT_DELETE DeleteProject
DeleteFolder
DeleteDataFlow
DeleteTask
DeleteTaskValidation
DeleteApplication
DeletePatch
DeleteTaskRun
DeleteDataAsset
DeleteConnection
DeleteConnectionValidation
DeleteDataFlowValidation
DeleteExternalPublication
DeleteExternalPublicationValidation
DeletePipeline
DeleteSchedule
DeleteTaskSchedule

MANAGE

USE +

USE +
DIS_WORKSPACE_CREATE CreateWorkspace
DIS_WORKSPACE_DELETE DeleteWorkspace
DIS_WORKSPACE_MOVE ChangeCompartment
DIS_WORKSPACE_START StartWorkspace
DIS_WORKSPACE_STOP StopWorkspace
Note

Each permission for dis-workspaces fully covers an API. There are no partially covered APIs for dis-workspaces permissions.

Permissions Required for Each API Operation

The following table lists the API operations for Oracle Cloud Infrastructure Data Integration in a logical order, grouped by resource-type.

The resource-types are dis-workspaces and dis-work-requests.

For information about permissions, see Permissions.

This table lists the API operations in a logical order, grouped by resource-type and the permissions required for dis-workspaces and dis-work-requests:

Required Permissions
API Operation Permissions
ListWorkspaces DIS_WORKSPACE_INSPECT
GetWorkspace DIS_WORKSPACE_READ
UpdateWorkspace DIS_WORKSPACE_UPDATE
DeleteWorkspace DIS_WORKSPACE_DELETE
CreateWorkspace DIS_WORKSPACE_CREATE
ChangeCompartment DIS_WORKSPACE_MOVE
StartWorkspace DIS_WORKSPACE_START
StopWorkspace DIS_WORKSPACE_STOP
ListWorkRequests DIS_WORK_REQUEST_INSPECT
GetWorkRequest DIS_WORK_REQUEST_READ
ListWorkRequestErrors DIS_WORK_REQUEST_INSPECT
ListWorkRequestLogs DIS_WORK_REQUEST_INSPECT
GetCountStatistic DIS_WORKSPACE_OBJECT_READ
ListProjects DIS_WORKSPACE_OBJECT_INSPECT
CreateProject DIS_WORKSPACE_OBJECT_CREATE
GetProject DIS_WORKSPACE_OBJECT_READ
UpdateProject DIS_WORKSPACE_OBJECT_UPDATE
DeleteProject DIS_WORKSPACE_OBJECT_DELETE
ListFolders DIS_WORKSPACE_OBJECT_INSPECT
CreateFolder DIS_WORKSPACE_OBJECT_CREATE
GetFolder DIS_WORKSPACE_OBJECT_READ
UpdateFolder DIS_WORKSPACE_OBJECT_UPDATE
DeleteFolder DIS_WORKSPACE_OBJECT_DELETE
ListDataFlows DIS_WORKSPACE_OBJECT_INSPECT
CreateDataFlow DIS_WORKSPACE_OBJECT_CREATE
GetDataFlow DIS_WORKSPACE_OBJECT_READ
UpdateDataFlow DIS_WORKSPACE_OBJECT_UPDATE
DeleteDataFlow DIS_WORKSPACE_OBJECT_DELETE
ListTasks DIS_WORKSPACE_OBJECT_INSPECT
CreateTask DIS_WORKSPACE_OBJECT_CREATE
GetTask DIS_WORKSPACE_OBJECT_READ
UpdateTask DIS_WORKSPACE_OBJECT_UPDATE
DeleteTask DIS_WORKSPACE_OBJECT_DELETE
CreateTaskValidation DIS_WORKSPACE_OBJECT_CREATE
ListTaskValidations DIS_WORKSPACE_OBJECT_INSPECT
GetTaskValidations DIS_WORKSPACE_OBJECT_READ
DeleteTaskValidation DIS_WORKSPACE_OBJECT_DELETE
ListApplications DIS_WORKSPACE_OBJECT_INSPECT
CreateApplication DIS_WORKSPACE_OBJECT_CREATE
GetApplication DIS_WORKSPACE_OBJECT_READ
UpdateApplication DIS_WORKSPACE_OBJECT_UPDATE
DeleteApplication DIS_WORKSPACE_OBJECT_DELETE
ListPatches DIS_WORKSPACE_OBJECT_INSPECT
CreatePatch DIS_WORKSPACE_OBJECT_CREATE
GetPatch DIS_WORKSPACE_OBJECT_READ
DeletePatch DIS_WORKSPACE_OBJECT_DELETE
ListPatchChangesDIS_WORKSPACE_OBJECT_INSPECT
ListPublishedObjects DIS_WORKSPACE_OBJECT_INSPECT
GetPublishedObject DIS_WORKSPACE_OBJECT_READ
ListDependentObjects DIS_WORKSPACE_OBJECT_INSPECT
GetDependenObject DIS_WORKSPACE_OBJECT_READ
ListTaskRuns DIS_WORKSPACE_OBJECT_INSPECT
CreateTaskRun DIS_WORKSPACE_OBJECT_EXECUTE
GetTaskRun DIS_WORKSPACE_OBJECT_READ
UpdateTaskRun DIS_WORKSPACE_OBJECT_UPDATE
DeleteTaskRun DIS_WORKSPACE_OBJECT_DELETE
ListTaskRunLogs DIS_WORKSPACE_OBJECT_INSPECT
CreateDataAsset DIS_WORKSPACE_OBJECT_CREATE
ListDataAssets DIS_WORKSPACE_OBJECT_INSPECT
GetDataAsset DIS_WORKSPACE_OBJECT_READ
UpdateDataAsset DIS_WORKSPACE_OBJECT_UPDATE
DeleteDataAsset DIS_WORKSPACE_OBJECT_DELETE
CreateConnection DIS_WORKSPACE_OBJECT_CREATE
ListConnections DIS_WORKSPACE_OBJECT_INSPECT
GetConnection DIS_WORKSPACE_OBJECT_READ
UpdateConnection DIS_WORKSPACE_OBJECT_UPDATE
DeleteConnection DIS_WORKSPACE_OBJECT_DELETE
GetSchema DIS_WORKSPACE_OBJECT_READ
ListSchemas DIS_WORKSPACE_OBJECT_INSPECT
ListDataEntities DIS_WORKSPACE_OBJECT_INSPECT
CreateEntityShape DIS_WORKSPACE_OBJECT_CREATE
GetDataEntity DIS_WORKSPACE_OBJECT_READ
CreateConnectionValidation DIS_WORKSPACE_OBJECT_CREATE
ListConnectionValidations DIS_WORKSPACE_OBJECT_INSPECT
GetConnectionValidation DIS_WORKSPACE_OBJECT_READ
DeleteConnectionValidation DIS_WORKSPACE_OBJECT_DELETE
CreateDataFlowValidation DIS_WORKSPACE_OBJECT_CREATE
ListDataFlowValidations DIS_WORKSPACE_OBJECT_INSPECT
GetDataFlowValidation DIS_WORKSPACE_OBJECT_READ
DeleteDataFlowValiation DIS_WORKSPACE_OBJECT_DELETE
ListReferencesDIS_WORKSPACE_OBJECT_INSPECT
GetReferenceDIS_WORKSPACE_OBJECT_READ
UpdateReferenceDIS_WORKSPACE_OBJECT_UPDATE
ListExternalPublicationsDIS_WORKSPACE_OBJECT_INSPECT
CreateExternalPublicationDIS_WORKSPACE_OBJECT_CREATE
GetExternalPublicationDIS_WORKSPACE_OBJECT_READ
UpdateExternalPublicationDIS_WORKSPACE_OBJECT_UPDATE
DeleteExternalPublicationDIS_WORKSPACE_OBJECT_DELETE
ListExternalPublicationValidationsDIS_WORKSPACE_OBJECT_INSPECT
CreateExternalPublicationValidationDIS_WORKSPACE_OBJECT_CREATE
GetExternalPublicationValidationDIS_WORKSPACE_OBJECT_READ
DeleteExternalPublicationValidationDIS_WORKSPACE_OBJECT_DELETE
ListPipelinesDIS_WORKSPACE_OBJECT_INSPECT
GetPipelineDIS_WORKSPACE_OBJECT_READ
UpdatePipelineDIS_WORKSPACE_OBJECT_UPDATE
CreatePipelineDIS_WORKSPACE_OBJECT_CREATE
DeletePipelineDIS_WORKSPACE_OBJECT_DELETE
ListSchedulesDIS_WORKSPACE_OBJECT_INSPECT
GetScheduleDIS_WORKSPACE_OBJECT_READ
UpdateScheduleDIS_WORKSPACE_OBJECT_UPDATE
CreateScheduleDIS_WORKSPACE_OBJECT_CREATE
DeleteScheduleDIS_WORKSPACE_OBJECT_DELETE
ListTaskSchedulesDIS_WORKSPACE_OBJECT_INSPECT
GetTaskScheduleDIS_WORKSPACE_OBJECT_READ
UpdateTaskScheduleDIS_WORKSPACE_OBJECT_UPDATE
CreateTaskScheduleDIS_WORKSPACE_OBJECT_CREATE
DeleteTaskScheduleDIS_WORKSPACE_OBJECT_DELETE

Creating a Policy Using the Console

You can use Data Integration policy templates to create a policy or you can manually enter the policy statements in the manual editor.

To create policies for a group of users, you need to know the name of the Oracle Cloud Infrastructure IAM group.

To create a policy:

  1. In the Console navigation menu, select Identity & Security, then under Identity, select Policies.
  2. Click Create Policy.
  3. Enter a Name and Description (optional) for the policy.
  4. Select the Compartment in which to create the policy.
  5. To use the manual editor, select Show manual editor. Then enter the policy statements you need.
  6. To use policy templates, do not select Show manual editor.
    1. From Policy use cases, select Data Integration.
    2. From Common policy templates, select a template.
    3. Select Groups and then select the group that you are creating the policy for.
    4. For Location, select the root compartment or the compartment in which the group is using Data Integration.
    5. (Optional) To give access to a specific workspace using the OCID of the workspace, you can customize the policy statements provided by the template. Select Show manual editor . Then in the manual editor, add request.principal.id='{workspace_ocid}' to applicable statements.
  7. (Optional) Select Create Another Policy to remain in the Create Policy page after creating this policy.
  8. To create this policy, click Create.

Complete information about using the Policy Builder and templates is found in Writing Policy Statements with the Policy Builder.

See also how policies work, policy syntax, and policy reference.

Policy Examples

The overall syntax of a policy statement is:

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

For a brief description of each variable, see Overview of Policy Syntax.

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

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.

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

  1. Create a user group and add users to the group.

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

  1. Define a policy with the following statements:

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

  2. 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 Data Flow Service

Before you can publish tasks from OCI Data Integration to OCI Data Flow, 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>
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>'}