Access control

Every member of your Org can see your product resources — clusters, Networks, monitors — but changing them is granted explicitly. Access is expressed as grants: a role, given to a member or machine user, org-wide or scoped to specific resources.

Roles

Each product ships three built-in roles:

Role	What it allows
Viewer	Read resources. Never returns a secret or credential.
Operator	Create, modify, and use resources — including fetching a cluster’s kubeconfig and generating single-use join commands.
Admin	Everything, including deletion and long-lived credentials such as registration tokens.

Each step up includes the ones below it. Two org-wide roles cover billing: Billing Viewer (see usage and invoices) and Billing Manager (manage the payment method and billing profile).

Membership itself carries one distinguished state: the org owner, who can always do everything — the recovery path if access is ever misconfigured. Everyone else is a member, and what a member can do is entirely a matter of grants. New members arrive with Platform Viewer — an ordinary, revocable grant of org-wide read across the products — so the default experience is “see everything, change nothing.” To make someone an administrator, grant them Organization Admin; to restrict someone below the default, remove their Platform Viewer grant and give something narrower, like Viewer on one cluster. There are no deny rules — access is always the sum of what’s granted.

Custom roles

If the built-in roles don’t match how your team works, author your own: give it a name and check the exact access it should carry, from a labelled grid of every permission the platform enforces. A custom role is then grantable exactly like a built-in one — define “Staging deployer” once and grant it wherever it fits, instead of re-assembling the same set of built-ins on every person. A custom role whose access is all within one scopable product (Control Plane or Mesh) can be granted on specific resources too; one that spans products is granted org-wide. Delete a role at any time — grants that referenced it stop conferring anything.

Grants

A grant gives one subject one role — either org-wide (every current and future resource) or scoped to specific resources (“Control Plane Operator on staging only”). Grants are additive: a subject’s access is the union of its grants on top of its membership baseline. Manage them in the Console under Organization → Access, or through the API:

POST /api/v1/grants
{ "subjectId": "…", "role": "controlplane.operator", "resourceIds": ["…"] }

Scoped grants are available for Control Plane clusters and Mesh Networks today; the other products take org-wide grants. Every grant and revocation appears in your Org’s audit log.

Machine users

A machine user starts with no access — grant it exactly what its automation needs. A CI machine user with Operator on your staging cluster can deploy there, and can’t touch production even if its token leaks. That bounded blast radius is the point: prefer one machine user per job over one broad token shared by everything.

Scoped personal tokens

A personal API token normally acts as you. When you mint one — from Profile → API tokens, choosing Limit to roles — you can narrow it to specific roles and resources, picked from the same catalog of built-in and custom roles you grant elsewhere (you can only scope a token to things you can already see). Its effective access is always the intersection of that scope and your own current access, so a token never outlives or exceeds what you can do yourself: if your own access shrinks later, so does the token’s. Leave a token acting as you only when it genuinely needs your full access (the lbr login default).