Databricks Workspace Permissions
You set up databricks workspace permissions by linking identity groups to workspace objects and roles. Admins assign these rules to control who can open notebooks, start clusters, and read data. Most engineering teams sync their main identity provider groups into the platform first. Then they grant broad group rights so data teams can start work fast. When roles stay too broad, any user can run wide queries or drop production tables. How databricks workspace permissions work in practice The p
AI Agent Permissions: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up databricks workspace permissions by linking identity groups to workspace objects and roles. Admins assign these rules to control who can open notebooks, start clusters, and read data. Most engineering teams sync their main identity provider groups into the platform first. Then they grant broad group rights so data teams can start work fast. When roles stay too broad, any user can run wide queries or drop production tables.
How databricks workspace permissions work in practice
The platform splits control into two main layers for your team. One layer governs workspace assets like folders, notebooks, jobs, and compute clusters. The other layer governs data objects like catalogs, schemas, tables, and views. Admins map users and groups from an identity provider into the account level.
From there, you assign specific groups to individual workspaces based on team needs. Inside a workspace, each asset has an access control list tied to those groups. You can let a group read a notebook, run a job, or restart a cluster. If you use the unified catalog, data rules live above the workspace level.
A user must pass both checks to run a query on a cluster. First, the workspace checks if the user can attach to the compute resource. Second, the catalog checks if the user can read the requested table or view. Service principals follow the same flow when automated apps or scripts log in.
Where native workspace roles fall short in production
Native roles do a great job of deciding who can log in and open assets. They also keep unauthorized teams out of private folders and shared compute pools. Still, static role assignments only check identity at the start of a session. They do not inspect what individual statements or commands do while in flight.
Once a developer has table read rights, every row in that table is open. A routine fixing query can pull thousands of customer emails or card numbers at once. Native roles also struggle when an engineer needs brief write rights to fix a bug. Admins often grant permanent write roles during an incident and forget to revoke them later.
AI Agent Permissions: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared service tokens create another blind spot for security and platform teams. When an app or script logs in with a static key, audit logs lose context. You can see the service account name, but not which human triggered the run. Native permissions alone cannot pause a risky query or require a quick peer approval first.
Best practices for safer data and compute rules
Start by removing direct user grants across all your workspaces and catalogs. Assign every rule to a synced identity group so changes happen in one place. Split your workspaces by environment so test users cannot touch production compute clusters. Give developers read rights by default and keep write rights tied to automated job roles.
Review your admin groups every month to remove people who changed teams. For sensitive tables, use dynamic views or row filters where your catalog supports them. Even with clean groups, remember that static roles cannot rewrite raw data on the fly. You still need runtime checks to mask fields like phone numbers or national IDs in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between account admins and workspace admins?
Account admins manage identity sync, billing, catalogs, and the creation of new workspaces. Workspace admins only manage users, clusters, jobs, and folders inside their own assigned workspace.
Should we assign permissions to individual users or groups?
Always assign permissions to groups rather than individual user accounts. Group rules are much easier to audit and update when team members join or leave.
Do workspace permissions control table data access on their own?
No, workspace permissions mainly control compute clusters, notebooks, folders, and scheduled jobs. Table and view access is governed separately through your catalog permission layer.