Spinnaker User Management Guide

• Model type: role-based
• Description: Spinnaker uses Fiat (its authorization microservice) to implement RBAC. Permissions are defined per-resource (application or account) and per-action (READ, WRITE, EXECUTE). Roles are sourced from an external provider (LDAP groups, GitHub Teams, Google Groups, SAML/OAuth2 group claims). Each Spinnaker application and account can have an explicit list of roles that are granted READ, WRITE, or EXECUTE. Users with no matching role for a resource cannot see or modify it.
• Custom roles: Yes
• Custom roles plan: Free (self-hosted open source) – roles are defined in the external role provider and referenced in Spinnaker resource configuration.
• Granularity: Per-resource (application and account level) with READ, WRITE, and EXECUTE permission types. Pipeline-level permissions are inherited from the application.

1. Configure an authentication provider (OAuth2, SAML 2.0, LDAP, or X.509) in Halyard using 'hal config security authn edit' commands.
2. Configure a role provider (LDAP, GitHub Teams, Google Groups, or SAML groups) in Halyard using 'hal config security authz edit' commands.
3. Enable authorization in Halyard: 'hal config security authz enable'.
4. Apply configuration: 'hal deploy apply'.
5. Assign the user to the appropriate groups in the external role provider (e.g., add them to the relevant LDAP group or GitHub Team).
6. In each Spinnaker application's configuration (Settings > Permissions), add the role name and grant READ, WRITE, or EXECUTE as needed.
7. For account-level access, edit the account configuration in Halyard to include the role under 'requiredGroupMembership' or the permissions block.
8. The user can now log in; Fiat resolves their roles from the external provider at login time.

Required fields: External identity provider account for the user, Group/role membership in the configured role provider, Role name referenced in Spinnaker application or account permissions

Watch out for:

• There is no 'create user' action inside Spinnaker. Users are provisioned entirely through the external IdP and role provider.
• If Fiat is enabled but a user has no matching roles for any resource, they will see an empty Spinnaker UI with no applications or accounts.
• Role membership is cached by Fiat; changes in the external role provider may not take effect immediately. Fiat syncs on a configurable interval.
• Enabling Fiat on an existing Spinnaker instance will immediately restrict access for all users who do not have matching roles configured.

• Can delete users: Unknown
• Delete/deactivate behavior: Spinnaker does not maintain an internal user database to delete from. To remove a user's access, revoke their membership from the relevant groups in the external role provider (LDAP, GitHub Teams, Google Groups, etc.). Fiat will deny access on the next role sync or login. There is no deactivate or delete action within Spinnaker itself.

1. Remove the user from the relevant groups in the external role provider (e.g., remove from LDAP group, GitHub Team, or Google Group).
2. Optionally, disable or delete the user's account in the external IdP to prevent authentication entirely.
3. Fiat will revoke access on its next sync cycle (interval is configurable) or immediately on the user's next request if the session is invalidated.

Watch out for:

• Fiat caches role memberships; a removed user may retain access until the next sync cycle completes.
• If the user has an active session, they may continue to operate until the session expires or Fiat invalidates it.
• Removing a user from the role provider does not delete any pipelines or resources they created.

• Where to check usage: Not documented
• How to identify unused seats: No built-in tooling for identifying unused user accounts. Operators can query Fiat's REST API (GET /v1/roles or /v1/users) to enumerate users who have authenticated and their current role assignments.
• Billing notes: Open source Spinnaker has no seat-based billing. Enterprise licensing through Armory or OpsMx is negotiated directly with those vendors and is not documented publicly.

Because Spinnaker holds no internal user records, access decisions for every app are delegated to an external identity and role provider at login time.

Onboarding a user means configuring the right IdP group memberships and then ensuring those role names are referenced in every app's permission block - a step that must be repeated per application with no bulk assignment available.

Offboarding requires removing the user from the external role provider, but Fiat caches role state on a sync interval, so access is not revoked instantly. An active session can persist until it expires or an admin manually triggers a role sync.

Community evidence is not specific enough to quote or summarize yet for this app.

Spinnaker suits teams that already operate a mature IdP (Okta, Entra ID, LDAP) and are comfortable managing access to every app entirely through group membership in that provider. It is a poor fit for teams expecting a point-and-click user management console or automated provisioning via SCIM. SAML 2.0 SSO is supported;

SCIM is not available in any tier. Teams evaluating enterprise distributions (Armory, OpsMx) should confirm authorization and provisioning capabilities directly with those vendors, as neither documents SCIM support publicly.

Bottom line

Spinnaker offloads every identity and access decision to an external provider - there is no user record to create, no seat to assign, and no deactivation toggle inside the platform itself.

That architecture keeps the open-source distribution free of per-seat cost but places the full operational burden of access governance on whoever manages the upstream IdP and role provider.

Teams without a disciplined group-management practice in their IdP will find role drift and sync lag to be ongoing operational costs.