Clarification on Automating Serverless Compute Permissions via SDK/API

[saicharan1]

Hi Team,

I'm trying to automate granting Can Use permissions on Default Interactive Compute for workspace groups across multiple Databricks workspaces. While reviewing the Serverless Compute access control documentation and the Access Control Rule Set APIs, I noticed that the examples require a resource name for get_rule_set() and update_rule_set(), but I couldn't find any documentation that explains how to discover the correct resource name for Default Interactive Compute or Default Automated Compute.

I also noticed that the Databricks Python SDK exposes WorkspaceClient.account_access_control_proxy with methods such as get_rule_set(), update_rule_set(), and get_assignable_roles_for_resource(). However, without knowing the resource name, it's unclear how these APIs can be used programmatically. 

Could someone clarify:

• How can we discover the correct resource name for Serverless Compute objects programmatically?
• Is there an API to list available Serverless Compute resources and their associated rule sets?
• Is Serverless Compute access control fundamentally a workspace-level permission model or an account-level one? The UI suggests each workspace has its own Default Interactive/Automated Compute objects, while the APIs appear to be account-focused.
• Is account_access_control_proxy the recommended SDK for this use case, or is there another supported SDK/API specifically intended for managing Serverless Compute permissions?

  Our goal is to automate permission assignment for groups across many workspaces, so any guidance on the correct endpoint, resource naming convention, or recommended SDK approach would be greatly appreciated.

  Thanks!
  
  Serverless compute access control - Azure Databricks

[srini_ve]

@saicharan1 

I believe there is a simpler approach for this use case.

The key point is that Default Interactive Compute and Default Automated Compute appear to be workspace-level Serverless Compute resources. Therefore, rather than using the account-level account_access_control_proxy Rule Set APIs, the more appropriate approach seems to be managing access through the workspace-level Permissions API using the serverless-compute object type.

Conceptually, the process would involve connecting to each Databricks workspace and identifying the built-in Serverless Compute resource, such as Default Interactive Compute or Default Automated Compute. Once the corresponding Serverless Compute object ID is identified, the workspace-level Permissions API can be used with the serverless-compute object type to assign the required CAN_USE permission to the relevant groups.

For example, the automation would need to:

1. Connect to each Databricks workspace.
2. Identify the Default Interactive Compute and/or Default Automated Compute resource.
3. Obtain the corresponding Serverless Compute object ID.
4. Use the workspace Permissions API with the serverless-compute object type.
5. Grant CAN_USE to the required groups.

The main challenge, however, is step 3. While the permission assignment itself appears relatively straightforward once the object ID is available, it is not clear from the documentation which API or SDK method should be used to discover the IDs for the built-in Default Interactive Compute and Default Automated Compute resources programmatically.

This is also why account_access_control_proxy is somewhat confusing in this scenario. The APIs exposed through that interface are account-oriented and require a resource name, but it is not clear whether the built-in Serverless Compute resources are exposed through those APIs or how their resource names can be discovered.

Since the Default Interactive Compute and Default Automated Compute resources are available separately within each workspace, the permission configuration appears to be workspace-specific, even if the groups being assigned are account-level groups.

Therefore, for automation across multiple workspaces, the expected approach would be to iterate through each workspace and apply the required permissions individually. However, to fully automate this, it would be very helpful to have a supported and documented way to discover the Serverless Compute resources and their associated object IDs.

If anyone from Databricks can clarify the supported API or SDK method for discovering these built-in Serverless Compute resources programmatically, that would help us complete the automation without relying on manually obtained IDs from the UI.

[ivanvyd]

@saicharan1 you found a gap in the Azure documentation🙂

Databricks creates Default Interactive Compute and Default Automated Compute objects in each workspace. Workspace admins manage their permissions, so you must grant CAN_USE in each workspace, even when you assign account-level groups.

For Azure, Databricks says:

“You can also manage permissions for serverless compute objects programmatically using the Account Access Control API.”

Manage serverless compute (Azure Databricks)

The missing piece is discovery. WorkspaceClient.account_access_control_proxy can get or update a rule set only after you supply its resource name. Databricks documents no list method or naming convention for the two default objects.

For AWS and GCP, Databricks states:

“Serverless compute objects use the serverless-compute object type, and each object is identified by its ID.”

Manage serverless compute (Databricks on AWS)

On AWS and GCP, you can use the workspace Permissions API once you have the object ID. Databricks does not document an endpoint for discovering those built-in IDs.

For Azure automation, I would avoid guessing resource names or assuming the AWS/GCP behavior applies. Ask your Databricks account team or support to confirm the supported discovery mechanism. Copying each ID from the workspace UI requires a manual bootstrap.