Permissions

Every action on the platform is listed, grouped by area, on the Permissions step of creating a custom role. This page covers the actions of access control itself.

Actions for access control

Action	Allows	Held by
rbac/members/read	Opening Access control (IAM): role assignments, roles, deny assignments, just-in-time requests; searching principals	Reader, Contributor, Owner, and the three platform roles
rbac/members/write	Assigning and removing roles, creating and deleting custom roles and deny assignments, deciding and revoking just-in-time requests	Owner, Platform Owner
rbac/members/admin	At the root: assigning principals from other tenants, and the Include other tenants switch; naming any principal in a deny assignment; requesting just-in-time access at the root	Platform Owner
rbac/users/list	At the root: searching principals across all tenants	The three platform roles
rbac/boundaryTrusts/admin	At the root: creating and removing boundary trusts	Platform Owner
rbac/idpBindings/admin	At the root: a tenant's single sign-on settings — see Single sign-on	Platform Owner, Platform Contributor
rbac/projector/read	At the root: reading the Kubernetes RBAC manifest a cluster needs — see Kubernetes RBAC	Platform Owner, Platform Contributor
rbac/projector/apply	At the root: applying the platform's RBAC to every cluster, with your own credentials	Platform Owner, Platform Contributor

Adding and removing boundary members and sending invitations are governed by boundaries/members/manage and boundaries/invitations/create — see Users and invitations.

What each task needs

To	You need
See Access control (IAM)	rbac/members/read
Assign or remove a role	rbac/members/write, and Owner or Platform Owner at the scope or above
Create or change a custom role	rbac/members/write, and Owner or Platform Owner on the boundary
Delete a custom role	rbac/members/write
Create or delete a deny assignment	rbac/members/write
Request just-in-time access	To be signed in and a member of the boundary's tenant
Approve, decline or revoke a just-in-time request	rbac/members/write on the boundary whose JIT access tab you use, and Owner or Platform Owner at the request's scope or above
Assign someone from another tenant	rbac/members/admin at the root — Platform Owner

Where this table asks for Owner or Platform Owner, the role must be assigned to you directly or held through an active just-in-time grant. Owner held through a group passes the rbac/members/write check, and the platform then refuses the change itself.

Root-scoped actions

These actions are only ever checked at the root scope /, whatever they concern. An assignment at a boundary never reaches them — Owner and Contributor list most of them through their */* wildcard, but assigned at a boundary they do not get them — so in practice they come from the platform roles.

Action	Controls	Platform Owner	Platform Contributor	Platform Reader
boundaries/create	Creating boundaries	Yes	Yes	No
boundaries/delete	Deleting boundaries	Yes	No	No
boundaries/projections/manage	Attaching boundaries to clusters and detaching them	Yes	Yes	No
boundaries/tenant/admin	Moving a boundary to another tenant	Yes	No	No
rbac/members/admin	Cross-tenant membership	Yes	No	No
rbac/users/list	Searching principals across tenants	Yes	Yes	Yes
rbac/idpBindings/admin	Tenants' single sign-on	Yes	Yes	No
rbac/boundaryTrusts/admin	Boundary trusts	Yes	No	No
rbac/projector/read, rbac/projector/apply	The Kubernetes RBAC manifest and applying it	Yes	Yes	No
lifecycle/view	Viewing the Lifecycle Manager	Yes	Yes	Yes
lifecycle/plan, lifecycle/install, lifecycle/execute, lifecycle/rollback	Planning, installing, running and rolling back platform upgrades	Yes	Yes	No
lifecycle/backupsManage	The platform backup target and schedule	Yes	No	No
monitoring/platform/read	Platform health and platform alerts	Yes	Yes	Yes
monitoring/platform/alerts/write	Raising and clearing platform alerts	Yes	Yes	No
sentinel/admin	Platform-wide Sentinel findings	Yes	Yes	No
kernel/platform/read	The platform's components and topology	Yes	Yes	Yes
kernel/platform/diagnose	A component's pods, events and database internals	Yes	No	No
kernel/emailTemplates/manage, kernel/emailSettings/manage	Email templates and email delivery settings	Yes	Yes	No
kernel/mcpSettings/manage	Turning the MCP interface for AI clients on and off	Yes	Yes	No
kernel/telemetrySettings/manage	Where the platform exports its own errors, metrics and traces	Yes	Yes	No
kernel/llmGateways/read	Viewing registered LLM gateways	Yes	Yes	Yes
kernel/llmGateways/write, kernel/llmGateways/delete	Registering, changing and removing LLM gateways	Yes	Yes	No
kernel/llmGateways/resolve	Resolving a gateway, including its API key	Yes	Yes	No
registry/audit/read	The container registry's audit log and retention sweep history	Yes	Yes	Yes
registry/retention/manage	Starting a registry retention sweep	Yes	Yes	No

The service roles Platform Alert Publisher and LLM Gateway Consumer hold monitoring/platform/alerts/write and kernel/llmGateways/resolve respectively.

The table is not an exhaustive list. The IAM reference in the RBAC docs lists every action with the built-in roles that grant it.