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.
Or, 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
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>
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
manage
verb to limit what the users can do. allow group <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>
Give Model Deployment Access to a Published Conda Bucket
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
allow any-user to use log-content in tenancy
where ALL {request.principal.type = 'datasciencemodeldeployment'}
Give Model Deployment Access to an Object Storage Bucket
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 as follows:
- 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' }
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.