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:

**Data Science Policy Variables**
Operations for This Resource Type...	Can Use These Variables...	Variable Type	Comments
`data-science-notebook-sessions`	`target.notebook-session.id`	Entity (OCID)	Not available to use with `CreateNotebookSession`
`data-science-notebook-sessions`	`target.notebook-session.createdBy`	String	Not available to use with `CreateNotebookSession`

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.

data-science-projects

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
`inspect`	`DATA_SCIENCE_PROJECT_INSPECT`	`ListProjects` `ListWorkRequests`	No extra
`read`	`inspect +` `DATA_SCIENCE_PROJECT_READ`	`inspect +` `GetProject` `GetWorkRequest`	`CreateNotebookSession` (You also need `manage data-science-notebook-sessions`.) `CreateModel` (You also need `manage data-science-models`.) `CreateJob` `CreateJobRun` (You also need `create data-science-job`.)
`use`	`read +` `DATA_SCIENCE_PROJECT_UPDATE`	`read +` `UpdateProject`	No extra
`manage`	`use +` `DATA_SCIENCE_PROJECT_CREATE` `DATA_SCIENCE_PROJECT_DELETE` `DATA_SCIENCE_PROJECT_MOVE`	`use +` `CreateProject` `DeleteProject` `ChangeProjectCompartment`	No extra

data-science-notebook-sessions

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
`inspect`	`DATA_SCIENCE_NOTEBOOK_` `SESSION_INSPECT`	`ListNotebookSessions` `ListNotebookSessionShapes` `ListWorkRequests`	No extra
`read`	`inspect +` `DATA_SCIENCE_NOTEBOOK_` `SESSION_READ`	`inspect +` `GetNotebookSession` `GetWorkRequest` `ActivateNotebookSession` `DeactivateNotebookSession`	No extra
`use`	`read +` `DATA_SCIENCE_NOTEBOOK_SESSION_OPEN` `DATA_SCIENCE_NOTEBOOK_SESSION_UPDATE`	`read +` `OpenNotebookSession` `UpdateNotebookSession` `ActivateNotebookSession` `DeactivateNotebookSession`	No extra
`manage`	`use+` `DATA_SCIENCE_NOTEBOOK_SESSION_CREATE` `DATA_SCIENCE_NOTEBOOK_SESSION_DELETE` `DATA_SCIENCE_NOTEBOOK_SESSION_MOVE` `DATA_SCIENCE_PRIVATE_ENDPOINT_READ` `DATA_SCIENCE_PRIVATE_ENDPOINT_ATTACH`	`use+` `CreateNotebookSession` `DeleteNotebookSession` `ChangeNotebookSessionCompartment` `ActivateNotebookSession`	`CreateNotebookSession` (You also need `read data-science-projects`.)

data-science-models

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
`inspect`	`DATA_SCIENCE_MODEL_INSPECT`	`ListModels` `ListWorkRequests`	No extra
`read`	`inspect +` `DATA_SCIENCE_MODEL_READ`	`inspect +` `GetModel` `GetModelProvenance` `GetModelArtifact` `GetWorkRequest`	No extra
`use`	`read +` `DATA_SCIENCE_MODEL_UPDATE`	`read +` `ActivateModel` `DeactivateModel` `UpdateModel` `UpdateModelProvenance`	No extra
`manage`	`use +` `DATA_SCIENCE_MODEL_CREATE` `DATA_SCIENCE_MODEL_DELETE` `DATA_SCIENCE_MODEL_MOVE`	`use +` `CreateModelArtifact` `CreateModelProvenance` `DeleteModel` `ChangeModelCompartment`	`CreateModel` (you also need `read data-science-projects` )

data-science-work-requests

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
`inspect`	`DATA_SCIENCE_WORK_REQUEST` `_INSPECT`	`ListWorkRequests`	No extra
`read`	`inspect +` `DATA_SCIENCE_WORK_REQUEST_READ`	`inspect +` `ListWorkRequestErrors` `ListWorkRequestLogs` `GetWorkRequest`	No extra
`manage`	`read +` `DATA_SCIENCE_WORK_REQUEST_DELETE`	`read +` `CancelWorkRequest`	No extra

data-science-model-deployments

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
`inspect`	`DATA_SCIENCE_MODEL_DEPLOYMENT_INSPECT`	`ListModelDeployment` `ListWorkRequests` `ListModelDeploymentShapes`	No extra
`read`	`inspect +` `DATA_SCIENCE_MODEL_DEPLOYMENT_READ`	`inspect +` `GetModelDeployment` `GetWorkRequest`	No extra
`use`	`read +` `DATA_SCIENCE_MODEL_DEPLOYMENT_UPDATE` `DATA_SCIENCE_MODEL_DEPLOYMENT_PREDICT`	`read +` `ActivateModelDeployment` `DeactivateModelDeployment` `UpdateModelDeployment` `PredictModelDeployment`	No extra
`manage`	`use +` `DATA_SCIENCE_MODEL_DEPLOYMENT_CREATE` `DATA_SCIENCE_MODEL_DEPLOYMENT_DELETE` `DATA_SCIENCE_MODEL_DEPLOYMENT_MOVE` `DATA_SCIENCE_PRIVATE_ENDPOINT_READ` `DATA_SCIENCE_PRIVATE_ENDPOINT_ATTACH`	`use +` `CreateModelDeployment` `DeleteModelDeployment` `ChangeModelDeploymentCompartment`	No extra

data-science-jobs

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
`inspect`	`DATA_SCIENCE_JOB_INSPECT`	`ListJobs` `ListJobShapes` `ListWorkRequests`	`CreateJobRun`
`read`	`inspect +` `DATA_SCIENCE_JOB_READ`	`inspect +` `GetWorkRequest`	`CreateJobRun` (You also need `read data-science-job` and `create data-science-job-run`.)
`use`	`read +` `DATA_SCIENCE_JOB_UPDATE`	`read +` `UpdateJob`	`CreateJobRun` (You also need `DATA_SCIENCE_JOB_READ`.)
`manage`	`use +` `DATA_SCIENCE_JOB_CREATE` `DATA_SCIENCE_JOB_DELETE` `DATA_SCIENCE_JOB_MOVE`	`use +` `DeleteJob` `ChangeJobCompartment`	`CreateJob`

data-science-job-runs

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
`inspect`	`DATA_SCIENCE_JOB_RUN_INSPECT`	`ListJobRuns`	No extra
`read`	`inspect +` `DATA_SCIENCE_JOB_RUN_READ`	`inspect +` `GetJobRun`	No extra
`use`	`read +` `DATA_SCIENCE_JOB_RUN_UPDATE`	`read +` `UpdateJobRun`	`CancelJobRun` (You also need `DATA_SCIENCE_JOB_RUN_READ`.)
`manage`	`use +` `DATA_SCIENCE_JOB_RUN_CREATE` `DATA_SCIENCE_JOB_RUN_DELETE` `DATA_SCIENCE_JOB_RUN_MOVE`	`use +` `CreateJobRun` `DeleteJobRun` `ChangeJobRunCompartment`	`CreateJob`

data-science-pipelines

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
`inspect`	`DATA_SCIENCE_PIPELINE_INSPECT`	`ListPipelines`	No extra
`read`	`inspect +` `DATA_SCIENCE_PIPELINE_READ`	`inspect +` `GetPipeline`	`CreatePipelineRun` (You also need `read data-science-projects`, `read data-science-pipeline` and `create data-science-pipeline-run`.)
`use`	`read +` `DATA_SCIENCE_PIPELINE_UPDATE`	`read +` `UpdatePipeline`	`CreatePipelineRun`, `GetPipeline` (You also need `DATA_SCIENCE_PROJECT_READ` and `DATA_SCIENCE_PIPELINE_READ`.)
`manage`	`use +` `DATA_SCIENCE_PIPELINE_CREATE` `DATA_SCIENCE_PIPELINE_DELETE` `DATA_SCIENCE_PIPELINE_MOVE`	`use +` `CreatePipeline` `DeletePipeline` `ChangePipelineCompartment`	`CreatePipeline` (You also need `read data-science-projects`.)

data-science-pipelineruns

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
`inspect`	`DATA_SCIENCE_PIPELINE_RUN_INSPECT`	`ListPipelineRuns`	No extra
`read`	`inspect +` `DATA_SCIENCE_PIPELINE_RUN_READ`	`inspect +` `GetPipelineRun`	No extra
`use`	`read +` `DATA_SCIENCE_PIPELINE_RUN_UPDATE`	`read +` `UpdatePipelineRun`	`CancelPipelineRun` (You also need `DATA_SCIENCE_PIPELINE_RUN_READ`.)
`manage`	`use +` `DATA_SCIENCE_PIPELINE_RUN_CREATE` `DATA_SCIENCE_PIPELINE_RUN_DELETE` `DATA_SCIENCE_PIPELINE_RUN_MOVE`	`use +` `CreatePipelineRun` `DeletePipelineRun` `ChangePipelineRunCompartment`	`CreatePipeline`

data-science-private-endpoint

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
`inspect`	`DATA_SCIENCE_PRIVATE_ENDPOINT_INSPECT`	`ListDataSciencePrivateEndpoint`	No extra
`read`	`inspect +` `DATA_SCIENCE_PRIVATE_ENDPOINT_READ`	`inspect +` `GetDataSciencePrivateEndpoint`	`CreateNotebookSession` `ActivateNotebookSession` `DeactivateNotebookSession` `CreateModelDeployment` `ActivateModelDeployment` `DeactivateModelDeployment`
`use`	`read +` `DATA_SCIENCE_PRIVATE_ENDPOINT_ATTACH` `DATA_SCIENCE_PRIVATE_ENDPOINT_DETACH`	`read +` `UpdateDataSciencePrivateEndpoint`	No extra
`manage`	`use +` `DATA_SCIENCE_PRIVATE_ENDPOINT_CREATE` `DATA_SCIENCE_PRIVATE_ENDPOINT_UPDATE` `DATA_SCIENCE_PRIVATE_ENDPOINT_DELETE` `DATA_SCIENCE_PRIVATE_ENDPOINT_MOVE`	`use +` `CreateDataSciencePrivateEndpoint` `DeleteDataSciencePrivateEndpoint` `ChangePrivateEndpointCompartment` `AttachPrivateEndpoint` `DetachPrivateEndpoint`	`CreatePrivateEndpoint` `CreateNotebookSession` `ActivateNotebookSession` `DeactivateNotebookSession` `CreateModelDeployment` `ActivateModelDeployment` `DeactivateModelDeployment`

Policy Examples

Note

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>

Note

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:

Allows a group of users, <group-name> to perform all CRUD operations on models stored in the model catalog. Any user who wants to deploy a model through model deployment also needs to access the model they want to deploy.

allow group <group-name> to manage data-science-models 
in compartment <compartment-name>

Allows a group of users, <group-name> to perform all CRUD operations, including calling the predict endpoint, on model deployment resources in a particular compartment. You can change the manage verb to limit what the users can do.

allow group <group-name> to manage data-science-model-deployments 
in compartment <compartment-name>

Lets a dynamic group of resources (such as notebook sessions) perform all CRUD operations, including calling the predict endpoint, on model deployment resources in a particular compartment. The 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>

Or, you can authorize resources to do the same. Only the dynamic group of resources in the specified dynamic group can call the model endpoint for the model deployment resources created in a specific compartment.

allow dynamic-group <dynamic-group-name-2> to {DATA_SCIENCE_MODEL_DEPLOYMENT_PREDICT} 
in compartment <compartment-name>

(Optional) Lets a model deployment access the published conda environments stored in an Object Storage bucket. This is required if you want to use Published Conda Environments to capture the third-party dependencies of a model.

allow any-user to read objects in compartment <compartment-name>
where ALL { request.principal.type='datasciencemodeldeployment', 
target.bucket.name=<published-conda-envs-bucket-name> }

(Optional) Lets a model deployment emit logs to the Logging service. You need this policy if you're using Logging in a model deployment. This statement is permissive. For example, you could restrict the permission to use log-content in a specific compartment.

allow any-user to use log-content in tenancy 
where ALL {request.principal.type = 'datasciencemodeldeployment'}

(Optional) Lets a model deployment access an Object Storage bucket that resides in a tenancy. For example, a deployed model reading files (a lookup CSV file) from an Object Storage bucket that you manage.

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:

Note

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>

Oracle Cloud Infrastructure Documentation

Policies

Resource Types

Supported Variables

Examples of Various Operations

Details for Verbs + Resource Type Combinations

Policy Examples

Example: List View

Example: All Operations

Examples: Manage All Resources

Policy Examples

Examples for Jobs and Job runs

Examples for Pipelines