User Roles and Permissions
Quave ONE uses role-based access control (RBAC) at the account level. Each member of an account can hold one or more roles, and each role grants specific capabilities.
Overview
When you create an account you automatically receive all available roles. You can then invite other members and assign any combination of roles to each person.
Roles are stored per account, so the same user can have different roles in different accounts.
Available Roles
| Role | Description |
|---|---|
| Admin | Full control over account settings. Revealing secrets requires Secrets Access. |
| Secrets Access | Allows revealing account and environment secrets. Credential secrets also require Manage Credentials. |
| Technical | Intended for team members involved in technical operations. |
| Billing | Receives billing-related email notifications such as payment failures, invoice reminders, and savings plan updates. |
| Pod Access | Allows opening terminal (exec) sessions inside running containers. |
| Manage Members | Allows inviting new members, updating roles, and removing members from the account. |
| Audit | Allows viewing the account activity log with all user actions. |
| Manage Credentials | Allows creating, updating and deleting account-level credentials (container registries, basic auth, TLS and ACME wildcard certificates) under My Account → Credentials. |
Secrets Access
Secrets Access is independent of Admin. It permits revealing account/environment secrets, including secret environment variables (and their history), environment CLI tokens, database connection credentials, backup decryption material, host private keys and sensitive contact-point configuration.
| Action | Required customer roles |
|---|---|
| Reveal environment/account secrets | Secrets Access, plus existing access to the resource |
| Manage a credential | Manage Credentials |
| Reveal a secret inside a managed credential or account LLM key | Manage Credentials and Secrets Access |
| Reference a credential without revealing its values | Existing resource permissions; no Secrets Access needed solely for the reference |
| Admin without Secrets Access | Administrative operations remain available; secret revelation is denied |
Existing Admin memberships and pending Admin invitations receive Secrets Access during the migration. Other roles are preserved; non-Admin members do not receive it automatically. After migration, adding Admin does not automatically add Secrets Access. New account creators still receive all roles. Grant Secrets Access explicitly to other members who need it.
Removing Secrets Access blocks subsequent reveal requests, including direct API/Meteor requests. A value already copied outside the platform cannot be recalled; rotate a secret if a former authorized reader must no longer know it.
Pod Access is separate: a terminal or code running in a container can read runtime environment variables. Secrets Access controls revelation by the platform, not code execution inside a workload. Ordinary environment variables are not automatically classified as secrets. Authorized internal Security access retains its separate, audited policy.
Managing Roles
To manage roles for account members:
- Go to your account Members page
- Click the role badges next to a members name
- Add or remove roles as needed
Role changes take effect immediately. When Admin is added or removed, an email notification is sent to the affected member.
Make sure at least one member retains the Admin role. Removing Admin from all members would lock everyone out of account management.
Environment-Level Access
Beyond roles, you can restrict which environments each member can see and interact with. This is an opt-in feature that admins enable on the Members page. Once enabled, you can assign specific environments when inviting someone, while the invitation is pending, or after they join.
For full details, see Per-Environment Member Access.