Account API and Workspace API RBAC

[Abishrp]

Hi,

Currently, for my use case, I am using a service principal with Account Admin permissions to call account-level APIs. For workspace-level APIs, I am using a separate service principal with Workspace Admin permissions.

Is there a way to avoid assigning the full Account Admin or Workspace Admin role to these service principals and instead grant only the minimum permissions required for the specific APIs they need to call?

I would also like to ensure that each service principal has access only to the required APIs and operations. For example, the account-level service principal should have only the necessary read/write permissions for the specific account-level APIs it uses, rather than having full Account Admin access.

Similarly, the workspace-level service principal should have only the required permissions for the specific workspace-level APIs.

I am looking for a least-privilege approach for assigning permissions to these service principals.

[balajij8]

@Abishrp 

Most of the platform level administrative APIs require full Account Admin or Workspace Admin privileges. At the account level - tasks like workspace creation, listing all workspaces, managing account-wide settings, handling workspace assignments and calling the Account SCIM API require the Account Admin role. Delegated roles like Service Principal Manager and Group Manager allow you to manage specific existing entities but they do not provide the broad API access needed for general account administration. Similarly, workspace-level administrative APIs like modifying workspace configurations, managing workspace identity settings, or assigning service principals to workspaces require Workspace Admin. Standard workspace entitlements (sql access, cluster create) govern what an identity can use within a workspace but they generally do not substitute for Workspace Admin when invoking administrative endpoints.

You can apply a least-privilege model when the service principals interacts with specific workspace resources rather than administering the platform itself. If the service principals execute tasks against data or compute assets, you can bypass admin roles entirely by leveraging resource-level Access Control Lists and Unity Catalog privileges. You can assign CAN MANAGE on specific jobs, CAN USE on designated SQL warehouses or granular USE CATALOG/SELECT privileges on Unity Catalog objects allows service principals to call the Jobs API, SQL Statement Execution API and Clusters API strictly scoped to needs.

You can audit and map the exact API endpoints each service principal calls to determine whether they are administrative or resource-specific

• Resource-Specific APIs - If the calls target specific workflows, compute, or tables, remove the admin roles and grant targeted Unity Catalog permissions directly on those resources.
• Administrative APIs - If the calls involve workspace-wide operations (listing all jobs across a workspace, creating service principals or altering tenant-level configurations), admin privileges are required.

For service principals that genuinely require Account Admin or Workspace Admin, you can mitigate risk through compensating controls - isolate them to dedicated administrative pipelines or workspaces, enforce strict secret/token rotation policies, monitor access patterns via Databricks system audit tables and restrict which environments are authorized to assume those credentials.