Serving endpoints access control

With Model Serving endpoint access control, individual permissions determine a user’s abilities. This article describes the individual permissions and how to configure Model Serving endpoints access control.

Endpoint permissions

No permissions are required to create an endpoint.

An endpoint is composed of served models, which are model versions from a registered model in Unity Catalog or the Workspace Model Registry.

If the model is from Workspace Model Registry, the creator of the endpoint must have Can Read permissions on the registered model of any model version that is specified in the endpoint configuration. If the model is from Unity Catalog, the creator of the endpoint must have the EXECUTE privilege on the registered model of any model version that is specified in the endpoint configuration, plus USE CATALOG and USE SCHEMA privileges on the parent catalog and schema of any such registered model.

Workspace admins automatically receive Can Manage permissions on all endpoints in the workspace, and the creator of an endpoint automatically receives Can Manage permissions on the created endpoint. By default, other users have No Permissions on a created endpoint and need to be granted permissions by users with Can Manage permissions.

There are three permission levels to serving endpoints: Can View, Can Query, and Can Manage.

The table lists the abilities for each permission:

Ability	No Permissions	Can View	Can Query	Can Manage
Create endpoint	x	x	x	x
Get endpoint		x	x	x
List endpoint		x	x	x
Query endpoint			x	x
Update endpoint config				x
Delete endpoint				x
Grant permissions to other users/principals				x

Use the API to modify permissions

You can manipulate the access control list for each endpoint using the permissions API, with the /permissions/serving-endpoints/ prefix for the API path. For example, to update the access control list, you can first get the endpoint UUID from GetInferenceEndpoint, and use it to call the permissions API:

$ curl -n -v -X GET -H "Authorization: Bearer $ACCESS_TOKEN" https://$WORKSPACE_URL/api/2.0/serving-endpoints/$ENDPOINT_NAME
// $ENDPOINT_ID = the uuid field from the returned object
$ curl -n -v -X PATCH -H "Authorization: Bearer $ACCESS_TOKEN" -d '{"access_control_list": [{"user_name": "jsmith@example.com", "permission_level": "CAN_QUERY"}]}' https://$WORKSPACE_URL/api/2.0/permissions/serving-endpoints/$ENDPOINT_ID

Recommendations for production serving endpoints

In accordance with best practices around managing production environments, Databricks recommends using service principals to create and manage serving endpoints. An advantage of service principals is that they are long-lived and not tied to a specific user in the workspace. If a user’s account is decommissioned, the user loses access to all Databricks objects.

A serving endpoint created by a decommissioned user continues to operate. However, updates fail because the creator does not have permissions over resources that are served by the endpoint.