RBAC

Who can use this dashboard, what they may do, and which resources they may do it to. A role is a named set of permissions you assign to a person or to a group from your identity provider; a workgroup is the other axis, and decides which VMs, databases and clusters they can see at all. Feature guide.

Username	Full Name	Email	Workgroups	Auth	MFA	Access	Status	Actions
No users found
			None

A service account is a workload, not a person: it has no password, cannot sign in, can never be an administrator, and holds nothing until a role or the grid below grants it. It authenticates with an OAuth client — create one from its OAuth clients button once it exists.

Username *

Full Name

Password * (leave blank to keep current)

Workgroups

Admin Active

Admin bypasses the permission grid entirely — every section, every level, plus the admin-only pages. The grid below is not consulted for this user.

Role (optional)

Permissions Full access (unrestricted)

Section	All
/
	/

No sections match “”.

of sections granted.

User has unrestricted access to all sections (stored as NULL permissions).

This service account will hold no access at all. Grant a role or at least one section — there is no “unrestricted” for a workload.

This user will be able to sign in and see nothing. Grant at least one section, or tick “Full access (unrestricted)”.

POV access (optional)

Leave empty for every POV. Naming one or more narrows this user to exactly those — a POV they were not granted answers "no such POV environment", and the POV list shows only theirs.

This user still has no POV permission, or unrestricted access, yet is narrowed to the environments above — that narrowing applies either way. Remove the entries to give them every POV.

API Tokens —

Token created — copy it now. It won't be shown again.

Name	Created	Expires	Last Used	Status

OAuth clients —

SVID client created: . There is no secret — the workload authenticates with its JWT-SVID.

Client secret issued — copy it now. It won't be shown again.

Client ID

Client secret

Exchange it for an access token: curl -u "$CLIENT_ID:$CLIENT_SECRET" -d grant_type=client_credentials

Registered on the dashboard's SPIRE server. The join token is one-use, lasts fifteen minutes and is not shown again.

Join token

Trust bundle — save as bootstrap.crt

Then, on the workload's host (examples/playbooks/spire/)

The host must reach on tcp/. Revoking this client also deletes the entry and evicts the node.

Name	Client ID	Secret expires	Last used	Status

External identities

Let a workload call with an access token from your IdP instead of a secret from this dashboard. The subject is the token's sub: Entra — the service principal's object id; Okta — the client id; Keycloak — the client's service-account user id. Requires workload tokens under Settings → Single sign-on.

Name	Subject	Issuer	Last used

SPIFFE trust domains

Trust a SPIRE trust domain's JWT-SVIDs as OAuth client assertions. Prefer a JWKS URL (SPIRE's OIDC Discovery Provider /keys) — it stays current as SPIRE rotates keys. A pasted bundle (spire-server bundle show -format spiffe) works anywhere but needs re-capturing after a rotation; a SPIRE lab can capture its own from the Workload Lab page.

Trust domain	Keys from
	— stale, re-capture

Map groups from your identity provider onto dashboard workgroups, a permission set and an access role. Members of a mapped group are provisioned automatically on first login — no manual user creation needed. Set up single sign-on.

Configured Mappings

No group mappings configured yet. Add one below.

Loading…

Display Name	Group Object ID	Role	Workgroup	Default Permissions
		—		Full access

Add Group Mapping

Display Name (friendly label, e.g. "Hydra Team")

Group Object ID (in Entra ID: Groups → your group → Object ID; on another provider, whatever value its groups claim emits)

Workgroup

Role (optional)

Every member of this group gets the role's permissions, re-applied at each sign-in. Anything ticked below is added on top of it.

Default Permissions for new users Full access (unrestricted)

Section	All
/
	/

No sections match “”.

of sections granted.

Auto-provisioned users will have unrestricted access (same as admins without the admin flag).

How it works

Users sign in via Sign in with Microsoft on the login page.
The group memberships in their token are checked against this table.
Matching users are auto-created and assigned the corresponding workgroup(s).
If a user is in multiple mapped groups they receive all matching workgroups.
Workgroup, permission and role assignments are re-synced from the provider on every login.

Required App Registration setup

Token configuration → Add groups claim → Security groups
API permissions → Microsoft Graph → Delegated: openid, profile, email

Assign a role instead of ticking permissions one by one. Editing a role changes it for everyone who holds it — immediately for users, and at next sign-in for members of a mapped group, whose permissions are rebuilt from their groups each time they log in.

You do not have access to role administration.

Role	Grants	Assigned to	Actions
Built-in Custom	Administrator — bypasses the permission grid Grants nothing
Loading… Users No users Group mappings — members pick a change up at their next sign-in No group mappings

No roles yet.

Loading…

Name

Description (optional)

Permissions

Section	All
/
	/

No sections match “”.

of sections granted.

This role grants nothing, so anyone holding it will be able to sign in and see nothing. Grant at least one section.

A workgroup is the other half of access control: the permission tabs decide what someone may do, and a workgroup decides which VMs, databases and clusters they may do it to. Each cloud resource is tagged with its workgroup, and a user sees only the ones they are assigned to. Administrators see everything. Feature guide.

All Workgroups

Loading…

No workgroups yet. Click "Create Workgroup" to add one.

Name	Display Name	Description	Local VM Path	Change window	Members
default				— misconfigured

Name (lowercase, hyphens, no spaces)

Name is immutable. Delete and recreate if you need to rename.

Display Name

Description (optional)

Local VM Path (optional, for VMware local-VM scanning)

Change window (optional) Require it — refuse any change to this workgroup outside the window Deploys, destroys and other gated actions are refused outside the window and offered a booking instead. Which actions count is the gated actions list in Settings → Action Guardrails; power operations are not on it by default. Pick a window first — requiring one with none chosen would refuse every change with nothing to book it into.

Mark as default workgroup