Pipeline Policies

Follow these steps to set up policies to use pipelines.

Bring Your Own Model

If bringing your own model, you need the following policies:

Resource Principal

Resource Principal-based authorization mechanism is used to pull the image from OCIR. You can use the ML Pipeline Run resource principal (datasciencepipelinerun) in the policies. You can choose whether to create the policies using dynamic groups or without dynamic groups. See the following steps:

User Principal

As only users with access to the container image can create an ML Pipeline using the image, a user-based IAM policy is required if access isn't implicitly propagated:
Allow group <GROUP_NAME> to read repos in tenancy where all {target.repo.name=<REPO_NAME>}
See the Container Registry documentation for more information on the user or group policy to access the image in OCIR.

Defining Policies Using Dynamic Groups

Create a dynamic group:
ALL { resource.type = 'datasciencepipelinerun' }
Create policies:
Allow dynamic-group <DYNAMIC GROUP> 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 you must allow reading for the tenancy:
Allow dynamic-group <DYNAMIC GROUP> to read repos in tenancy where ANY {
    request.operation='ReadDockerRepositoryMetadata',
    request.operation='ReadDockerRepositoryManifest',
    request.operation='PullDockerLayer'
}
Note

Specific operation permissions are added to the policy to limit the OCIR operations to only pull images.

Defining Policies without Dynamic Groups

You can directly write the policies based on the resource without creating a dynamic group:
allow any-user to read repos in compartment <YOUR COMPARTMENT NAME> where ALL { request.principal.type = 'datasciencepipelinerun'}
If the repository is in the root compartment you must allow reading for the tenancy:
Allow any-user to read repos in tenancy where ALL { request.principal.type = 'datasciencepipelinerun' }

Custom Networking Policy

For custom networking, add a policy to provide Data Science access to the subnet

Add the following policy:

Allow service datascience to use virtual-network-family in compartment <subnet_compartment>

This policy is already being used by Data Science services such as Jobs, Model Deployments, and Notebooks. The same policy is used for ML Pipelines, too. If you're already using the custom networking feature in Notebooks or Jobs, this policy is already in place and need not be applied again.

If this policy definition isn't in place, pipeline creation fails. Details can be found in the Troubleshooting section.

Logging Policy

When you use logs in the pipelines, you need to define a policy that lets pipeline runs use them.

Consider adding this policy and using logs, otherwise, you can't troubleshoot the pipelines:
Allow group <GROUP_NAME> to read repos in tenancy where all {target.repo.name=<REPO_NAME>}