Roles and teams
Assign organization and project permissions and inspect effective access.
Role bindings grant members, teams, and service accounts permission to operate Infra resources. Bindings specify a role and a scope.
Built-in roles
Built-in roles separate organization, fleet, project, and audit authority:
| Role | Scope | Capabilities |
|---|---|---|
| Organization Owner | Organization | Ownership, billing, access policy, and administration |
| Organization Admin | Organization | Projects, membership, region policy, and fleet administration |
| Infrastructure Operator | Organization or selected regions | Nodes, maintenance, storage pools, and fleet operations |
| Project Operator | Selected projects | Workload creation, configuration, and lifecycle actions |
| Project Viewer | Selected projects | Resource configuration, health, and permitted history |
| Auditor | Organization or selected projects | Audit and policy records without resource mutation |
| Billing Viewer | Organization | Usage, allocation, and billing records |
Guest Console permission is separately assignable. A custom role can permit resource inspection without opening a guest terminal or reading sensitive integration configuration.
Bind a team
Open Organization settings → Teams, select a team, and add a role binding. Choose the narrowest scope that covers the intended work. A project binding does not grant host administration merely because that project's droplets run on a host.
Team membership can be managed locally or through SSO. Removing a user from a team removes that team's grants after access state is refreshed. Independent direct bindings and other team bindings remain effective.
Effective permissions
Permissions from valid bindings are combined. An additional narrow binding does not reduce broader access inherited elsewhere. The Effective permissions view shows the binding responsible for each grant.
Review organization grants when a supposedly restricted operator can still modify another project. API keys are constrained by both their scopes and their service account's role bindings.
Custom roles
Custom roles and permission simulation select named permissions for resource reads, writes, lifecycle actions, guest access, exports, and policy administration. The editor lists required dependencies, such as read access needed to operate on a resource.
A role revision affects its active bindings. Preview the affected principals before changing a shared role. Removing a permission can cause a running multi-step automation workflow to fail on its next authorized request.
Remove access
To disable a member, open Organization settings → Members, select the member, and choose Disable. Review their active sessions in the member's session view and revoke them when terminating an existing sign-in.
To remove a team grant without disabling the member, open Organization settings → Teams, select the team, and remove its role binding. Then inspect Effective permissions for grants from other teams or direct bindings. Removing one binding does not remove those independent grants.
For machine access, revoke the key or disable its service account.
For work already accepted, follow the credential-exposure procedure
to find active operations and cancel those whose cancelable field is true.
Revocation alone does not stop accepted work.
When a member leaves, review their owner-team references under Organization settings → Service accounts and assign a current administrator. Resource ownership remains with the organization or project; it does not transfer as a result of removing membership.
Audit
Membership, role, binding, and permission changes appear in the audit log. Keep an organization recovery owner outside routine SSO administration and validate that account through the organization's access recovery procedure.
Temporary grants provide bounded elevation without permanent team edits. Access API distinguishes requested grants, approval, effective bindings, and explicit revocation.