Model Deployment Policies

You must create a group of users that are authorized to work with model deployments before you can deploy a model with a model deployment resource.

Alternatively, you could create a dynamic group of resources (like notebook sessions) that is authorized to create a deployment. In this case, anyone who can access the notebook session can take the identity of the notebook session and create a model deployment. The authentication method from the notebook session uses resource principals.

The same pattern applies when invoking the model endpoint after deployment. A group of users or resources need to be authorized to invoke the model.

We believe that the following examples are the most common policy statements for use with a model deployment and example model deployment policies contains more examples.

Manage Model Deployment Policies

Allows a group of users, <your-group> 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 <your-group> to manage data-science-models 
in compartment <your-compartment-name>

Allows a group of users, <your-group> 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 <your-group> to manage data-science-model-deployments 
in compartment <your-compartment-name>

Allows a dynamic group of resources (like notebook sessions) to 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 <your-dynamic-group> to manage  data-science-model-deployments 
in compartment <your-compartment-name>

The preceding policy examples are permissive. You can create more restrictive policies. A common example is to restrict who or what resources can invoke the predict endpoint of the model deployment.

Authorize Access to Predict Endpoint Policy

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

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

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

Give Model Deployment Access to Your Published Conda Bucket

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

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

Give Model Deployment Access to the Logging Service

(Optional) Allows a model deployment to emit logs to the Logging service. You need this policy if you’re using Logging in your Model Deployment. This statement is very 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'}

Give Model Deployment Access to an Object Storage Bucket

(Optional) Allows a model deployment to access an Object Storage bucket that resides in your 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 <your-compartment-name> 
where ALL { request.principal.type='datasciencemodeldeployment', target.bucket.name=<your-bucket-name> }

Other Methods of Authentication and Authorization

Model deployment only supports authorization and authentication defined by the OCI Identity and Access Management (IAM) service. Model deployment does not support other methods of authorization and authentication such as OAuth or basic access authentication.