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 (such as notebook sessions) that's 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, <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>

Allows a dynamic group of resources (such as 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 <dynamic-group-name> to manage  data-science-model-deployments 
in compartment <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 <group-name> to manage data-science-model-deployments 
in compartment <compartment-name>

Alternatively, 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>

Give Model Deployment Access to a Published Conda Bucket

(Optional) Allows a model deployment to 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> }

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 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'}

Give Model Deployment Access to an Object Storage Bucket

(Optional) Allows a model deployment to 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> }

Give Model Deployment Access to a Custom Container Using Resource Principal

Policies can be configured in one of these two ways:

Configuring Dynamic Groups and Creating Policies in the Dynamic Group

Create a dynamic group:

ALL { resource.type = 'datasciencemodeldeployment' }

Allows a dynamic group to read a custom container.

allow dynamic-group <dynamic-group-name> to read repos in compartment <compartment-name> where ANY {
    request.operation='ReadDockerRepositoryMetadata',
    request.operation='ReadDockerRepositoryManifest',
    request.operation='PullDockerLayer'

If the repository is in the root compartment, allow read for the tenancy:

allow dynamic-group <dynamic-group-name> to read repos in tenancy where ANY {
    request.operation='ReadDockerRepositoryMetadata',
    request.operation='ReadDockerRepositoryManifest',
    request.operation='PullDockerLayer'
}

Configuring User Policies

Because only users with access to the container image can create a model deployment using the image, a user-based IAM policy is required if access isn't implicitly propagated.

Directly write user policies based on the resource without using a dynamic group:

allow any-user to read repos in tenancy where ALL { request.principal.type = 'datasciencemodeldeployment' }
 
allow any-user to read repos in compartment <compartment-name> 
where ALL { request.principal.type = 'datasciencemodeldeployment'}

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 doesn't support other methods of authorization and authentication such as OAuth or basic access authentication.

Oracle Cloud Infrastructure Documentation