Policies
To control who has access to Data Science and the type of access for each group of users, you must create policies.
To monitor Data Science resources, you must be given the required access in a policy. This is true whether you're using the Console or the REST API with an SDK, CLI, or other tool. The policy must give you access to the monitoring services and the resources being monitored. If you try to perform an action and get a message that you don't have permission or are unauthorized, confirm with an administrator the type of access you've been granted, and which compartment you can work in. For more information on user authorizations for monitoring, see the Authentication and Authorization section for the related service, Monitoring or Notifications.
By default, only the users in the Administrators
group have access to all Data Science resources. For everyone else who's involved with
Data Science, you must create new policies that assigns them
proper rights to Data Science resources.
For a complete list of OCI policies, see Policy Reference.
Resource Types
Data Science 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 data-science-projects
,
data-science-notebook-sessions
, data-science-models
, and
data-science-work-requests
, you can have a policy that allows the group to
manage the aggregate resource type, data-science-family
.
Aggregate Resource Type
data-science-family
Individual Resource Types
data-science-projects
data-science-notebook-sessions
data-science-models
data-science-model-deployments
data-science-work-requests
data-science-jobs
data-science-job-runs
data-science-pipelines
data-science-pipeline-runs
data-science-private-endpoint
Supported Variables
To add conditions to your policies, you can either use OCI general variables or service-specific variables.
Data Science supports the General Variables for All Requests for use with resources and these service specific variables:
Operations for This Resource Type... |
Can Use These Variables... |
Variable Type |
Comments |
---|---|---|---|
|
|
Entity (OCID) |
Not available to use with |
|
String |
Not available to use with |
The user that creates a notebook is the only user that can open and use it.
Examples of Various Operations
allow group <data_science_hol_users> to manage data_science_projects
in compartment <datascience_hol>
allow group <data_science_hol_users> to manage data_science_models
in compartment <datascience_hol>
allow group <data_science_hol_users> to manage data_science_work_requests
in compartment <datascience_hol>
allow group <data_science_hol_users> to inspect data_science_notebook_sessions
in compartment <datascience_hol>
allow group <data_science_hol_users> to read data_science_notebook_sessions
in compartment <datascience_hol>
allow group <data_science_hol_users> to {DATA_SCIENCE_NOTEBOOK_SESSION_CREATE}
in compartment <datascience_hol>
allow group <data_science_hol_users> to
{DATA_SCIENCE_NOTEBOOK_SESSION_DELETE,DATA_SCIENCE_NOTEBOOK_SESSION_UPDATE,DATA_SCIENCE_NOTEBOOK
_SESSION_OPEN,DATA_SCIENCE_NOTEBOOK_SESSION_ACTIVATE,DATA_SCIENCE_NOTEBOOK_SESSION_DEACTIVATE}
in compartment <datascience_hol>
where target.notebook-session.createdBy = request.user.id
Details for Verbs + Resource Type Combinations
There are various OCI verbs and resource types that you can use to create a policy.
A policy syntax is like this:
allow <subject> to <verb> <resource_type> in <location> where <conditions>.
The following describe the permissions and API operations covered by each verb for Data Science. 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.
The APIs covered for the data-science-projects
resource-type are listed
here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
|
|
|
|
No extra |
|
|
|
No extra |
The APIs covered for the data-science-notebook-sessions
resource-type are
listed here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
No extra |
|
|
|
No extra |
|
|
|
|
The APIs covered for the data-science-models
resource-type are listed here.
The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
No extra |
|
|
|
No extra |
|
|
|
|
The APIs covered for the data-science-work-requests
resource-type are listed
here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
No extra |
|
|
|
No extra |
The APIs covered for the data-science-model-deployments
resource-type
are listed here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
No extra |
|
|
|
No extra |
|
|
|
No extra |
The APIs covered for the data-science-jobs
resource-type are listed
here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The APIs covered for the data-science-job-runs
resource-type are listed here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
No extra |
|
|
|
|
|
|
|
|
The APIs covered for the data-science-pipelines
resource-type are listed here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
|
|
|
|
|
|
|
|
(You also need |
The APIs covered for the data-science-pipelineruns
resource-type are listed here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
No extra |
|
|
|
|
|
|
|
|
The APIs covered for the data-science-private-endpoint
resource-type are listed here. The APIs are displayed alphabetically for each permission.
Verbs |
Permissions |
APIs Fully Covered |
APIs Partially Covered |
---|---|---|---|
|
|
|
No extra |
|
|
|
|
|
|
|
No extra |
|
|
|
|
Policy Examples
The APIs cover the Data Science aggregate
data-science-family
and individual resource types. For
example, allow group <group_name> to manage data-science-family in
compartment <compartment_name>
is the same as writing the
following four policies:
allow group <group_name>> to manage <data_science_projects> in compartment
<compartment_name>
allow group <group_name> to manage data-science-notebook-sessions in compartment
<compartment_name>
allow group <group_name> to manage data-science-models in compartment
<compartment_name>
allow group <group_name> to manage data-science-work-requests in compartment
<compartment_name>
For a step by step guide to configuring policies, see: Creating Policies in the Manually Configuring a Data Science Tenancy tutorial.
Example: List View
Allows a group to simply view the list of all Data Science models in a specific compartment:
allow group <group_name> to inspect data-science-models in compartment
<compartment_name>
The read
verb for data-science-models
covers the
same permissions and API operations as the inspect
verb with the
DATA_SCIENCE_MODEL_READ
permission and the API operations that
it covers, such as GetModel
and GetModelArtifact
.
Example: All Operations
Allows a group to perform all the operations listed for
DATA_SCIENCE_MODEL_READ
in a specified compartment:
allow group <group_name> to read data-science-models in compartment
<compartment_name>
The manage
verb for data-science-models
includes
the same permissions and API operations as the read
verb, plus the
APIs for the DATA_SCIENCE_MODEL_CREATE
,
DATA_SCIENCE_MODEL_MOVE
,
DATA_SCIENCE_MODEL_UPDATE
, and
DATA_SCIENCE_MODEL_DELETE
permissions. For example, a user can
delete a model only with the manage permission or the specific
DATA_SCIENCE_MODEL_DELETE
permission. With a
read
permission for data-science-models
, a
user cannot delete the models.
Examples: Manage All Resources
Allows a group to manage all the resources for Data Science use:
allow group <group_name> to manage <data_science_family> in compartment
<compartment_name>
Allows a group to manage all the Data Science resources, except for deleting the Data Science projects:
allow group <group_name> to manage <data_science_family> in compartment
<compartment_name> where request.permission !='DATA_SCIENCE_PROJECT_DELETE'
The APIs covered for the data-science-projects
resource-type are
listed here. The APIs are displayed alphabetically for each permission.
Policy Examples
We identified these policy statements that you're likely to adopt in a tenancy for model deployments:
allow group <group-name> to manage data-science-models
in compartment <compartment-name>
manage
verb to limit what the users can do. allow group <group-name> to manage data-science-model-deployments
in compartment <compartment-name>
manage
verb can be changed to limit what the resources can do. allow dynamic-group <dynamic-group-name> to manage data-science-model-deployments
in compartment <compartment-name>
allow dynamic-group <dynamic-group-name-2> to {DATA_SCIENCE_MODEL_DEPLOYMENT_PREDICT}
in compartment <compartment-name>
allow any-user to read objects in compartment <compartment-name>
where ALL { request.principal.type='datasciencemodeldeployment',
target.bucket.name=<published-conda-envs-bucket-name> }
allow any-user to use log-content in tenancy
where ALL {request.principal.type = 'datasciencemodeldeployment'}
allow any-user to read objects in compartment <compartment-name>
where ALL { request.principal.type='datasciencemodeldeployment', target.bucket.name=<bucket-name> }
Examples for Jobs and Job runs
(Optional) You can integrate logging for jobs. When enabled, the job run resource requires permissions to emit logs to the Logging service. You must create a job runs dynamic group with:
all { resource.type='datasciencejobrun', resource.compartment.id='<job-run-compartment-ocid>' }
Then allow this dynamic group to write to the Logging service logs:
allow dynamic-group <job-runs-dynamic-group> to use log-content in compartment <your-compartment-name>
Lastly, the user starting the job runs must also have access to use log groups and logs:
If you use an instance principal dynamic group to create and start job runs, then
you must apply group policies to the dynamic group. Specifically, the instance
principal should have the to manage log-groups
policy set.
allow group <group-name> to manage log-groups in compartment <compartment-name>
allow group <group-name> to use log-content in compartment <compartment-name>
(Optional) There are no additional policies required to run jobs with a Data Science conda environment. To run jobs with a published custom conda environment, the job run resource requires permissions to download the conda environment from your tenancy's Object Storage. You must allow the job runs dynamic group to access objects in your compartment with:
allow dynamic-group <job-runs-dynamic-group> to read objects in compartment <compartment-name> where target.bucket.name='<bucket-name>'
To be able to pull the container image from OCIR, add this policy:
allow dynamic-group <your-dynamic-group> to read repos in compartment <compartment-name>
If your repository is in the root compartment, you must allow read for the tenancy with:
allow dynamic-group <your-dynamic-group> to read repos in tenancy where all {target.repo.name=<repository-name>}
Examples for Pipelines
Data Science uses other OCI services to execute pipelines, mainly jobs. To function properly, pipelines require permissions to operate those resources on your tenancy or compartment. You have to create dynamic groups and policies to use Data Science pipelines.
Create a new dynamic group or update an existing dynamic group to add the following rows:
To allow pipeline runs to access OCI services like Logging, Networking, Object Storage, and so on:
all {resource.type='datasciencepipelinerun',resource.compartment.id='ocid1.compartment.oc1..<>'}
If your pipeline includes at least one job as a step, you have to allow the job run to access resources:
all {resource.type='datasciencejobrun',resource.compartment.id='ocid1.compartment.oc1..<>'}
When working from notebook sessions using Resource Principal authentication, you'll need to allow the notebook to access resources:
all {resource.type='datasciencenotebooksession',resource.compartment.id='ocid1.compartment.oc1..<>'}
Now, add the relevant policies to allow your dynamic group to access the resources in a compartment or tenancy. Following are some useful example policies for your dynamic group:
(Optional) Allow to manage all Data Science resources like notebooks, jobs, pipelines, and so on:
allow dynamic-group <YOUR_DYNAMIC_GROUP_NAME> to manage data-science-family in compartment <YOUR_COMPARTMENT_NAME>
(Optional) Allow to use networking including the use of OCI Object Storage and File Storage Service:
allow dynamic-group <YOUR_DYNAMIC_GROUP_NAME> to use virtual-network-family in compartment <YOUR_COMPARTMENT_NAME>
(Optional) Allow to manage Object Storage:
allow dynamic-group <YOUR_DYNAMIC_GROUP_NAME> to manage objects in compartment <YOUR_COMPARTMENT_NAME>
(Optional) Allow to log to Logging service logs:
allow dynamic-group <YOUR_DYNAMIC_GROUP_NAME> to use log-content in compartment <YOUR_COMPARTMENT_NAME>