Data Flow Policies
To control who has access to Data Flow, and the type of access for each group of users, you must create policies.
By default only the users in the Administrators group have access to all
Data Flow resources. For everyone else who's
involved with Data Flow, you must set up policies that assign them proper
rights to Data Flow resources.
For a complete list of Oracle Cloud Infrastructure policies, see policy reference.
Resource-Types
Data Flow 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 dataflow-application and dataflow-run, you
can have a policy that allows the group to manage the aggregate resource-type,
dataflow-family.
| Aggregate Resource-Type | Individual Resource-Types |
|---|---|
dataflow-family |
|
Supported Variables
To add conditions to the policies, you can either use Oracle Cloud Infrastructure general or service specific variables.
|
Operations for This Resource Type... |
Can Use These Variables... |
Variable Type |
Comments |
|---|---|---|---|
|
|
|
Entity (OCID) |
Not available to use with |
|
|
|
Entity (OCID) |
Not available to use with |
|
|
Entity (OCID) |
Give the user who created a run some permission for that run. For example, allow that user to cancel that run. |
|
|
|
|
||
|
|||
|
|
Not available to use with |
|
|
|
|
Entity (OCID) |
Allow a specified group to use the SQL endpoint. |
|
|
Entity (OCID) |
Give the user who created a SQL endpoint some permission for it. Give the user who created a SQL endpoint some permission for that SQL endpoint. For example, allow that user to use the SQL endpoint.. |
Example:
allow group <group_name> to use dataflow-application in compartment <compartment_name> where target.application.id = '<some_application_OCID>'allow group <group_name> to manage dataflow-run in in compartment Ccompartment_name> where target.run.id != '<some_run_id>'allow group <group_name> to manage dataflow-run in <tenancy> where target.user.id = request.user.idThe last example shows that the user who creates a run is the only one who can manage that run. That is, only that user can update, move or cancel that run.
allow group <group_name> to use dataflow-sqlendpoint in compartment <compartment_name> where target.dataflow-sqlendpoint.id = '<sql-endpoint-ocid>'allow group <group_name> to use dataflow-sqlendpoint where request.permission=DATAFLOW_SQL_ENDPOINT_CONNECTallow group <group_name> to use dataflow-sqlendpoint where target.user.id = request.user.idDetails for Verbs + Resource-Type Combinations
The following tables show the permissions and API operations covered by each verb for
Data Flow. The level of access is cumulative as you go
from inspect > read > use > 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.
| Verb | Permissions | APIs Fully Covered | APIs Partially Covered |
|---|---|---|---|
|
INSPECT |
DATAFLOW_APPLICATION_INSPECT |
|
none |
|
READ |
INSPECT + DATAFLOW_APPLICATION_READ |
INSPECT +
|
none |
|
USE |
READ + DATAFLOW_APPLICATION_UPDATE |
READ +
|
none |
|
MANAGE |
USE + DATAFLOW_APPLICATION_CREATE, DATAFLOW_APPLICATION_DELETE |
USE +
|
none |
| Verb | Permissions | APIs Fully Covered | APIs Partially Covered |
|---|---|---|---|
|
INSPECT |
DATAFLOW_RUN_INSPECT |
|
none |
|
READ |
INSPECT + DATAFLOW_RUN_READ |
INSPECT
+
|
none |
|
USE |
READ + DATAFLOW_RUN_UPDATE |
READ +
|
none |
|
MANAGE |
USE+ DATAFLOW_RUN_CREATE, DATAFLOW_RUN_DELETE |
USE+
|
none |
| Verb | Permissions | APIs Fully Covered | APIs Partially Covered |
|---|---|---|---|
|
INSPECT |
DATAFLOW_POOL_INSPECT |
|
none |
|
READ |
INSPECT + DATAFLOW_POOL_READ |
INSPECT +
|
none |
|
USE |
READ + DATAFLOW_POOL_UPDATE |
READ +
|
none |
|
MANAGE |
USE+ DATAFLOW_POOL_CREATE DATAFLOW_POOL_DELETE DATAFLOW_POOL_MOVE |
USE+
|
none |
| Verb | Permissions | APIs Fully Covered | APIs Partially Covered |
|---|---|---|---|
|
INSPECT |
DATAFLOW-SQLENDPOINT_INSPECT |
|
none |
|
READ |
INSPECT + DATAFLOW-SQLENDPOINT_READ |
INSPECT +
|
none |
|
USE |
READ + DATAFLOW-SQLENDPOINT_UPDATE |
READ +
|
none |
|
MANAGE |
USE+ DATAFLOW-SQLENDPOINT_CREATE DATAFLOW-SQLENDPOINT_DELETE DATAFLOW-SQLENDPOINT_MOVE DATAFLOW-SQLENDPOINT_UPDATE |
USE+
|
none |
The APIs covered for the aggregate
dataflow-family resource-type cover the
APIs for dataflow-application and dataflow-run. For example,
allow group dataflow-admins to manage dataflow-family in compartment x is the
same as writing the following two
policies:allow group dataflow-admins to manage dataflow-application in compartment xallow group dataflow-admins to manage dataflow-run in compartment xPermissions Required for Each API Operation
The following table lists the API operations in a logical order, grouped by resource
type. The resource types are dataflow-application and
dataflow-run.
For information about permissions, see permissions.
|
API Operation |
Permissions Required to Use the Operation |
|---|---|
|
|
DATAFLOW_APPLICATION_INSPECT |
|
|
DATAFLOW_APPLICATION_READ |
|
|
DATAFLOW_APPLICATION_UPDATE |
|
|
DATAFLOW_APPLICATION_CREATE |
|
|
DATAFLOW_APPLICATION_DELETE |
|
|
DATAFLOW_RUN_INSPECT |
|
|
DATAFLOW_RUN_READ |
|
|
DATAFLOW_RUN_CREATE |
|
|
DATAFLOW_RUN_UPDATE |
|
|
DATAFLOW_RUN_DELETE |
|
|
DATAFLOW_RUN_INSPECT |
|
|
DATAFLOW_RUN_READ |
|
|
DATAFLOW_RUN_READ |
|
|
DATAFLOW_RUN_READ |
|
|
DATAFLOW_POOL_CREATE |
|
|
DATAFLOW_POOL_CREATE |
|
|
DATAFLOW_POOL_CREATE |
|
|
DATAFLOW_POOL_INSPECT |
|
|
DATAFLOW_POOL_READ |
|
|
DATAFLOW_POOL_UPDATE |
|
|
DATAFLOW_POOL_DELETE |
|
|
DATAFLOW_POOL_MOVE |
CreateSqlEndpoint |
DATAFLOW-SQLENDPOINT_CREATE |
|
|
DATAFLOW-SQLENDPOINT_READ |
|
|
DATAFLOW-SQLENDPOINT_DELETE |
|
|
DATAFLOW-SQLENDPOINT_INSPECT |
|
|
DATAFLOW-SQLENDPOINT_CONNECT |
|
|
DATAFLOW-SQLENDPOINT_MOVE |