- Billing Account
- Organization
Billing accounts have three roles that can be assigned when inviting users:
| Role | Description |
|---|---|
billing_admin | Full administrative access to billing settings and invoices |
billing_viewer | Read-only access to billing information |
org_creator | Ability to create new organizations under the billing account |
Principals
A “principal” is an entity that can be granted permissions. The Control Plane Platform supports four principal types, each scoped to an org.User
A distinct human being associated with an email. Users are members of one or more orgs and can be invited by authorized principals.
Service Account
A non-human principal for automation and CI/CD pipelines. Service accounts can be associated with a group on creation.
Group
A named collection of users and service accounts. Permissions granted to a group via policies are automatically applied to all its members.
Identity
A workload identity that grants cloud access and network resource permissions. Reusable across multiple workloads.
Policy
A policy governs resource access within an org by binding principals to permissions on target resources.Target Resources
Target Resources
A resource is a Control Plane object (e.g., secret, workload, GVC, etc.).A policy can target:
- All resources of a specific type within your org
- Specific resources assigned directly by resource self link
- Dynamic resources matched using tag queries
Bindings
Bindings
A binding maps permissions to principals:
- Permissions: Actions like
create,delete,edit,view, etc. The available permissions vary by resource type. - Principals: Users, groups, service accounts, or identities that receive the permissions.
Common Use Cases
Team access via groups
Team access via groups
Create a group for your team and add users as members. Create a policy that grants the group permissions on target resources (e.g.,
view and edit on specific GVCs). All group members automatically receive these permissions. When team members change, simply update group membership - no policy changes needed.CI/CD automation with service accounts
CI/CD automation with service accounts
Create a service account and generate a key for authentication. Add the service account to a group with appropriate permissions, or create a policy granting it
create and edit permissions on workloads. Create a CLI profile using cpln profile create PROFILE_NAME --org ORG_NAME --token KEY --default. The --default flag makes this profile active for all future commands without needing to specify --profile each time.Workload access to secrets
Workload access to secrets
Infrastructure as Code automation
Infrastructure as Code automation
Create a service account for Terraform or Pulumi. Generate a key and configure your provider to authenticate with it. Create policies granting the service account permissions to manage the resources your IaC templates define (GVCs, workloads, secrets, identities, etc.).