Serving endpoints access control
This article describes how to configure permissions on serving endpoints
Note
Access control is available only in the Premium plan or above.
Endpoint permissions
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.
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 |
|---|---|---|---|---|
Get endpoint |
x |
x |
x |
|
List endpoint |
x |
x |
x |
|
Query endpoint |
x |
x |
x |
|
Update endpoint config |
x |
x |
||
Edit job settings |
x |
|||
Delete endpoint |
x |
|||
Modify permissions |
x |
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.
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.