Skip to main content
Role-based access control (RBAC) decides what each member, service account, and API key can do in your organization. You give each of them one or more roles. A principal can do everything that any of its roles allows.

​
How roles work

  • Roles compose. Roles are capabilities, not job titles. A principal holds the union of its roles. For example, an infrastructure engineer can hold Operator and Platform Admin, and someone who also manages people adds Manager.
  • Roles apply across the organization. You assign a role to a member or a service account for the whole organization. The role’s statements decide which resources it reaches.
  • Deny wins. A statement can allow or deny actions. A matching deny overrides every allow. When nothing allows an action, Ravion denies it.
  • No one can grant more than they hold. You can add or remove a role only when you already hold every permission in that role.

​
System-managed roles

Ravion maintains these roles and updates them as new features ship. They’re available on every plan. Every role except Billing can read everything in the organization except billing and authorization policy. Only Owner and Billing include billing, and only Owner and Manager can see and change who has which permissions.
Operators can start pipeline runs and deploy modules without administering cloud accounts or execution environments. They only need to read those resources to use them.

​
Common combinations

​
Assign roles to members

A member holds at least one role. Setting a member’s roles replaces the whole set. To assign roles in the dashboard:
  1. Go to Settings → Members.
  2. Select the member. To give roles to someone new, click Invite member and pick their Roles in the invite dialog.
  3. Under Roles, click Add role and choose a role, or remove one the member holds.
The role list includes your organization’s custom roles. It only offers roles whose permissions you already hold. To change them from the CLI, use ravion membership with --roles:
assignable-roles lists the roles you can give, which are the roles whose permissions you already hold.

​
Service accounts

Service accounts hold roles the same way members do, with a few limits:
  • A service account can’t hold Owner or any role that can delete the organization.
  • A service account holds at least one role.
  • To create a key for a service account, or to widen what a key can do, you must hold every action that the key could perform.
To assign roles in the dashboard, go to Settings → Service Accounts and select the service account.
See ravion service-account for every flag.

​
Limit API key permissions

An API key acts as its owner. You can give a key a permission limit so it does less than its owner can. A key can do something only when both its limit and its owner allow it, so a limit narrows the owner’s permissions but never widens them. Permissions are type:action pairs from the authorization catalog, for example project:read or pipelineRun:create. To set a key’s limit in the dashboard:
  1. Go to Settings → API keys and select the key, or click API key to create one. You can also create a key for a member from their page under Settings → Members.
  2. Under Permissions, choose one:
    • Same as the owner: the key follows its owner’s permissions, including any the owner gets later.
    • Read only: the key can only read the resource types you check, where its owner has access.
    • Custom: the key can do only what you check, and only where its owner can too. Permissions the owner doesn’t have are greyed out.
  3. Save the key.
From the CLI:
A key with a limit can’t use the Terraform Cloud API or personal-account operations, and can’t select another organization. Only a member signed in to the dashboard or the CLI can change a key’s limit. See ravion api-key for details.

​
Roles from Flightcontrol

If your organization used Flightcontrol membership roles, Ravion maps them to system-managed roles: Restricted Developer maps to Read only because system-managed roles can’t express a protected-environment limit. Use a custom role to let these members deploy everywhere except production.

​
Need finer control?

System-managed roles cover most teams. When you need to limit access to specific projects, environments, or module types, or deny particular actions, create custom roles. Custom roles require the Security and compliance bundle.