Role-Based Access Control (RBAC)

Roles

Signadot supports Role-Based Access Control with three roles: admin, member, and viewer.

• admin — Full access to everything in the organization, including administration and management functions.
• member — Read access to everything, plus write access (create, update, delete) to application-related entities. Cannot perform administration or management functions.
• viewer — Read-only access. Cannot modify any resource, and additionally cannot read the audit log or other users' API-key metadata.

These roles apply to both users and service accounts (non-human principals used for automation). A service account's API keys inherit the account's role.

Permissions

All three roles can read most entities and functions pertaining to their organization. Write access (create, update, delete), and a small number of sensitive reads, vary by role. The table below charts it out:

	admin	member	viewer
Read most entities (sandboxes, clusters, plans, tests, settings, …)	✅	✅	✅
Read the audit log (events)	✅	✅	❌
Read other users' API-key metadata	✅	✅	❌
Write: Sandboxes	✅	✅	❌
Write: Resource Plugins	✅	✅	❌
Write: Route Groups	✅	✅	❌
Write: Tests, Jobs, Plans, Devboxes, Saved Requests	✅	✅	❌
Write: JobRunnerGroups	✅	❌	❌
Write: Clusters & Cluster Tokens	✅	❌	❌
Write: Secrets	✅	❌	❌
Write: Service Accounts & API Keys	✅	❌	❌
Write: Users & User Invites	✅	❌	❌
Write: Settings (SSO, Authorized Domains, Preserved Labels)	✅	❌	❌
Write: Billing	✅	❌	❌

In short: admin can do everything, member adds write access to application entities on top of read access, and viewer is read-only (and is additionally blocked from the audit log and other users' API-key metadata).

Admins can review the full role-by-permission breakdown in the Dashboard on the "Users" page, via View role permissions.

Role Assignment

When creating an organization
The user creating an organization will automatically assume the admin role. This ensures that there is at least one admin who has full control over the organization's settings and operations from the outset.

When inviting a user
A role can be assigned at the time of inviting a user. This allows the organization's admin(s) to control the level of access a new user will have right from the start.

Upon Auto-Provisioning
Users auto-provisioned based on Authorized Domains or SSO Auto-provisioning settings are assigned the member role by default.

When creating a service account
A service account is assigned its role at creation time, and an admin can change it later. Every API key the account holds inherits the account's role.

Role Management

admins can manage user roles from the Dashboard on the "Users" page, and service account roles on the "Service Accounts" page under Settings. In both cases the role is changed from the role dropdown on the user's or service account's detail page.

An organization must always retain at least one admin: the last remaining admin cannot be demoted.