Two grammars at a glance
A user can be a Control Plane Admin (full org control) while having no Compute Plane permissions in a given workspace - and vice versa. A request always hits exactly one plane, and only that plane’s check applies.
Control Plane permissions
Control Plane authorization uses a fixed set of named permissions. Each is a literal<verb>:<resource> string, checked against the exact value - there are no wildcards.
The complete lookup, with a description of each permission, lives in the Permissions matrix reference.
Built-in roles
Every organization starts with three built-in roles:Compute Plane permissions
The Compute Plane uses a more granular resource × action grammar, because data operations are more varied than org management. A role is a named bundle of rules, and each rule pairs one or more resources with one or more actions.Resources
Compute Plane resources are the things you operate inside a workspace - your catalogs, clusters, scheduled refreshes, data governance policies, service accounts, and access tokens. A wildcard (*) covers every resource type.
Actions
Granting
* for an action means “every defined action on the listed resources.” At decision time the platform always tests a concrete action (for example, a cluster scale), so wildcards never cause ambiguity.
Roles and role bindings
A role by itself grants nothing. A role binding attaches a role to a subject - a user, group, or service account - and optionally scopes it to a specific resource.
Why scoping matters. Without scoping, “give the BI team read-only access to one catalog” would need a custom role that mentions only that catalog. With scoping, you reuse a generic
catalog-reader role and create a binding whose scope names that catalog - far fewer roles to maintain.
Expiring bindings. A binding can carry an expiry time. After it passes, the binding is excluded from permission evaluation automatically - you don’t have to delete it. This is useful for time-bound access, such as a contractor engagement.
How a permission decision is made
On the Compute Plane, the authorization service evaluates every request as follows:- Authenticate - identify the caller and the groups they belong to.
- Gather bindings - collect every role binding that references the caller or any of their groups.
- Expand to permissions - resolve each binding’s role to its resource + action rules.
- Filter by scope - keep only bindings whose scope matches the target resource. A workspace-wide binding always matches; otherwise the resource type and name must match.
- Match the requirement - the required permission is
<resource>.<action>. If the granted set contains it (expanding any wildcards), allow; otherwise return403.
Permissions are additive
Effective permissions are the union of a subject’s direct role bindings and the bindings of every group they belong to. There are no deny rules - to restrict access, remove or narrow a binding rather than adding a negative one. Overlapping grants are harmless; the decision is simply “is the required permission in the union?”Subjects
Every Compute Plane binding attaches to one of three subject kinds:
The match key is
<Kind>:<name>, so a user binding never collides with a group of the same name.
See also
- Roles and permissions - built-in and custom roles in detail.
- Permissions matrix - the complete permission lookup.