Access Control

​

What a Policy Contains

​

Principals

​

Key Behaviors

• Every org starts with policies already written. Creating one sets up a superusers group, an empty read-only viewers group, and built-in policies for every resource kind, binding manage to superusers and view to viewers.
• Identities are how workloads get access. Attach an identity to a workload and credentials arrive at runtime, stored nowhere in the container. A group holds only users and service accounts, so an identity is always named directly in a binding.
• Grant to a group, and membership does the rest. Bind the group once: adding a member gives them everything the group’s policies grant, and removing them takes it back, with no policy edited either way.
• A target can be a query, so resources that do not exist yet are already covered. A query on tags, properties, or relations runs again on every request, so a resource created later that matches is covered with no edit to the policy.
• Permissions imply each other. manage covers create, delete, edit, and view, and edit covers view, so a binding usually names one permission rather than a list. What each one drags along differs per resource kind, and edit on a secret grants reveal. See the permission model.
• Every resource can show who reaches it. An Access Report lists the permissions on a resource, the principals bound to each, and which policy granted them, in the Console or through cpln <kind> access-report. It names the groups in a binding rather than expanding them to people.
• The controlplane service account is bound like any other principal. The superusers- policy for every resource kind names it alongside the group, which is how the platform operates the resources in your org. It shows up in the policy list and in every Access Report, exactly like a grant you wrote.

​

Gotchas

• No policy can deny. A principal is allowed the moment any policy matches, and nothing subtracts from what another granted, so narrow access by granting less rather than by writing an exception.
• Billing reaches into the org twice. Creating an org needs billing_admin or org_creator on the account, and an unpaid account deactivates its orgs: every principal collapses to read-only whatever the policies say, with This org is inactive and only read access is allowed.
• Group edits apply at once; user edits may not. Changing a group’s members or its query takes effect immediately. Membership that a query derives from user data is cached, so retagging a user is not a reliable way to revoke access. In a SAML org, membership can also come from the assertion’s own claims.
• A policy cannot reach someone who is not yet an org member. Control Plane resolves a non-member to a principal no org policy can name, and skips group expansion for them entirely, so a binding on their email address grants nothing until they join the org. Invite first, then grant.
• You cannot lock yourself out of superusers. Removing yourself from the built-in group is refused with You cannot remove yourself from the built-in 'superusers' group.

​

Learn More

Policy reference

The permission table per resource kind, and the policies every org starts with.

Create a Policy

Grant a group or an identity permission on a set of resources.

Identity

What you attach to a workload to give it secrets, clouds, and private networks.

Org (Organization)

The boundary every policy lives in, and the users, groups, and service accounts it holds.