Dev.to
7/2/2026
![[Databricks on AWS #2] RBAC on Databricks: Function-Role Groups, Workspace Assignment, and Why USER/ADMIN Isn't the Whole Story](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F19ibyyz1lfu3admgcpzm.png)
[Databricks on AWS #2] RBAC on Databricks: Function-Role Groups, Workspace Assignment, and Why USER/ADMIN Isn't the Whole Story
Short summary
Design Databricks RBAC by creating function-role groups to abstract permissions, assigning each to workspaces (ADMIN/USER), and keeping user membership outside IaC to avoid redeployment churn. Databricks provides four permission primitives; you design the subjects—the groups. Apply group definitions before workspace assignments or risk silent dependency failures.
- •Create function-role groups (ai_admin, ai_engineer, ai_analyst) as the single layer you control; Databricks provides four other permission layers built-in
- •Assign groups to workspaces (ADMIN/USER) in IaC; manage user membership separately via console/SCIM to avoid constant pull requests
- •Apply group definitions before workspace assignment stack or dependencies silently resolve to empty assignments
Generated with AI, which can make mistakes.
Is this a good recommendation for you?



