> ## Documentation Index > Fetch the complete documentation index at: https://docs.e6data.com/llms.txt > Use this file to discover all available pages before exploring further. # Control Plane vs Compute Plane permissions > The two permission grammars in e6data - Control Plane named permissions and Compute Plane resource-and-action rules - and how roles and bindings compose them. e6data uses **two permission grammars**. The Control Plane and Compute Plane protect different surfaces, so they keep separate vocabularies. This page explains both grammars, the built-in roles, and how a permission decision is made. ## Two grammars at a glance | | Control Plane | Compute Plane | | - | - | - | | Grammar | `:` | `` × `` | | Example | `write:groups`, `read:invitations` | catalogs × `read`, clusters × `scale` | | Where defined | Built-in, managed through the Management API | Workspace roles you define | | Built-in roles | Admin, Manager, Viewer | A small set of built-ins | | What it gates | Org management: users, groups, workspaces, SSO, invitations, service credentials | Data operations: queries, catalogs, schedules, governance | 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 `:` string, checked against the exact value - there are no wildcards. | Resource family | Permissions | | - | - | | Workspaces | `read:workspaces`, `write:workspaces`, `delete:workspaces` | | Users | `read:users`, `write:users`, `delete:users` | | Groups | `read:groups`, `write:groups`, `delete:groups` | | Service Accounts | `read:service-accounts`, `write:service-accounts`, `delete:service-accounts` | | Roles | `read:roles`, `manage:roles` | | Invitations | `read:invitations`, `write:invitations` | | Organization | `manage:organization` | The complete lookup, with a description of each permission, lives in the [Permissions matrix](/platform/reference/permissions-matrix) reference. ### Built-in roles Every organization starts with three built-in roles: | Role | Intended use | Permissions held | | - | - | - | | Admin | Full org control. The first user gets this automatically. | All Control Plane permissions. | | Manager | Manage workspaces and invite users. | `read:workspaces`, `write:workspaces`, `read:users`, `read:roles`, `read:invitations`, `write:invitations`, `read:groups`, `write:groups`, `read:service-accounts`, `write:service-accounts` | | Viewer | Read-only across the organization. | `read:workspaces`, `read:users`, `read:groups`, `read:service-accounts`, `read:roles`, `read:invitations` | ## 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 | Family | Actions | | - | - | | CRUD | `create`, `read`, `update`, `delete`, `list` | | Lifecycle | `suspend`, `resume`, `scale`, `run`, `stop`, `configure` | | Maintenance | `refresh`, `sync`, `compact`, `upgrade`, `revoke` | | Wildcard | `*` | 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. | Binding shape | Scope | Effect | | - | - | - | | Workspace-wide | No scope set | The role applies to all resources of all matching types in the workspace. | | Resource-type scoped | A resource type (for example, all catalogs) | The role applies to every resource of that type, but no others. | | Resource-named scoped | One named resource | The role applies to exactly that one 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: 1. **Authenticate** - identify the caller and the groups they belong to. 2. **Gather bindings** - collect every role binding that references the caller or any of their groups. 3. **Expand to permissions** - resolve each binding's role to its resource + action rules. 4. **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. 5. **Match the requirement** - the required permission is `.`. If the granted set contains it (expanding any wildcards), allow; otherwise return `403`. The **Control Plane** is simpler - there is no scoping, only the named-permission check: authenticate, collect the caller's permissions from their direct roles and group roles, and allow if the required permission string is in that set. ### 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: | Kind | `name` is… | Where the identity comes from | | - | - | - | | User | An email address (`alice@acme.com`) | Propagated from the Control Plane, or created locally on first login | | Group | A group name (`analytics`) | Synced from the Control Plane, or created on the workspace | | Service Account | A service account identifier | Created on the workspace; exists only there | The match key is `:`, so a user binding never collides with a group of the same name. ## See also * [Roles and permissions](/platform/identity/roles-and-permissions) - built-in and custom roles in detail. * [Permissions matrix](/platform/reference/permissions-matrix) - the complete permission lookup. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.