RBAC roles¶

Ampora has three roles. Roles are assigned per-tenant; a single user can have different roles across tenants in a multi-tenant deployment.

Role boundaries at a glance¶

Operators handle day-to-day fleet management. Admins handle the infrastructure of the management plane itself.

Multi-role users¶

A user can hold different roles in different tenants. The role chip in the top-right always reflects the active tenant; switching tenant also switches the active role.

In multi-tenant deployments, the OIDC role claim per tenant is read from the IdP — typically via group membership scoped to the tenant ("ampora-eu-admins" → Admin in tenant eu).

Approval requirements override role¶

Even Admins cannot approve their own changes. An Admin who creates a custom policy must wait for another Admin to approve. See Approval flows.

"First user becomes Admin"¶

The first user to log in to a brand-new Ampora is bootstrapped as Admin regardless of OIDC claim. After that, the OIDC mapping takes over. This bootstrap is a one-shot — there is no way to trigger it again without a database reset.

Role escalation¶

A Viewer does not see actions they cannot perform; the buttons are not present. An Operator sees admin-only buttons but they are disabled with a tooltip explaining what is needed. This is by design — discoverability for the next-step role, no accidental clicks for the current role.

Escalation requests are out-of-band: an Operator who needs Admin for one specific action asks an existing Admin to do it (or to escalate their role in the IdP).

Service accounts¶

For automation, issue PATs (Personal Access Tokens) under Settings → Tokens → API tokens. The PAT holds:

• a single role (Viewer / Operator / Admin),
• an optional allow-list of API endpoints (e.g. "only /api/configurations and /api/rollouts"),
• a TTL.

PATs do not own audit events under a user identity; they own them under their own PAT name. This makes it easy to spot "the gitops-sync-bot PAT did this" in the audit log.