Spinnaker – Authorization (RBAC)

Docs: Google Groups

Mon, 01 Jan 0001 00:00:00 +0000

Service account setup

In order to access a user’s group membership, we must use the Google Admin Directory API. We will setup a Google Cloud Platform (GCP) service account and grant it access to the Directory API.

Enable the Admin SDK here .
In your Cloud Console , create a service account that will access the G Suite Directory API.
1. Navigate to the “IAM & Admin” –> Service accounts section.
2. Click “Create Service Account.”
3. Give it a name like “spinnaker-fiat.”
4. Select “Furnish a new private key” and select the JSON format.
5. Select “Enable G Suite Domain-wide Delegation.”
6. Click “Create”, which should download the private key for your new service account (see figure below).
7. Transfer this JSON file to a known location in your Spinnaker deployment.
8. You should see your newly created service account in the list, along with “DwD” and an option to “View Client ID”. Click “View Client ID” (see figure below).
9. Note the Client ID displayed. It will be used in the next step.
Give your service account access to the G Suite Directory API in the G Suite Admin console .
1. Navigate to the “Security” Settings page.
2. Under “Advanced settings”, click “Manage API client access.”
3. Enter the Client ID noted above under “Client Name.”
4. Enter https://www.googleapis.com/auth/admin.directory.group.readonly as the API scope.
5. Click “Authorize.”

Configure Fiat

NOTE you’ll want to make sure fiat is enabled in the spinnaker.yml file as it defaults to disabled at this point in time. It’s likely to become mandatory in a future release.

Make sure you’ve configured roles for accounts, as described here . Each role included in the command must match the name of a group in the organization.
With the authorized service account’s credentials in hand, add the following to fiat-local.yml

auth:
  group-membership:
    service: google
    google:
      credentialPath: /mnt/something/sa-creds.json
      adminUsername: emailOfServiceAccount
      domain: googleappsworkspacedomain
      ## this defaults to false.
      expandIndirectGroups: false|true
      ## this is a new parameter to parallel query the google APIs to lookup group information.
      groupLookupConcurrency:  10

Docs: LDAP

Mon, 01 Jan 0001 00:00:00 +0000

Please note that LDAP is flexible enough to offer lots of other options and configuration possibilities. Spinnaker uses the Spring Security libraries, which solve a number of challenges.

Configure fiat

With the LDAP manager credentials and search patterns in hand, add the following to fiat-local.yml

auth:
  group-membership:
    service: ldap
    ldap:
      url: ldaps://something.com
      managerDn: dn=something
      managerPassword: encrypted:secretPlease
      userSearchBase: searchBase
      groupSearchBase: ""
      ## optional, defaults to the uid={-},ou=users
      userDnPattern: uid={0},ou=users
      ## user search fitler defaults to null but could be set like so
      userSearchFilter: (employeeEmail={0})
      ## Defaults to uniqueMember={0}
      groupSearchFilter: (uniqueMember={0})
      ## defaults to cn
      groupRoleAttributes: cn
      groupUserAttributes: nullByDefault
      thresholdToUseGroupMembership: 100
      enablePagingForGroupMembershipQueries: false
      pageSizeForGroupMembershipQueries: 100
      loadUserDNsBatchSize: 100
      userIdAttribute: employeeEmail
      enableDnBasedMultiLoad: false
      cache:
        ## Defaults to false.  Enable to reduce LDAP load
        enabled: true
        expireAfterWriteSeconds: 600

See the ldap configuration code for more information on each setting.

How Fiat determines group membership

The LDAP provider works by querying the LDAP server utilizing a user as set by the manager-dn and manager password and making a query that uses the logged-in user’s username to filter results.

Fiat will use the “bound” account to do the following:

Make a query using a base of groupSearchBase. THIS IS A REQUIRED FIELD. If not set, no roles get queried.
That query uses groupSearchFilter to find the results.
This uses a parameter of the user’s full DN as a filter. This means the ONLY groups shown are those which the user is a member.
For the groups retrieved, get the role names. This uses the groupRoleAttributess attribute (defaults to cn).

How to determine the “Full DN”

Extract the Root DN from the url (ldaps://my.server/a/b/c → a/b/c)

If com.netflix.spinnaker.fiat.roles.ldap.LdapUserRolesProvider log level is at debug, you should see Root DN: <the actual root DN extracted>
If userSearchFilter is provided then:
- Search LDAP:
  - For userSearchBase
  - Using userSearchFilter aka (uid={0})
- Return root DN computed + found user DN
ELSE when userSearchFilter is not provided:
- Make user DN using userDnPattern
- Return root DN computed + user DN

You must provide either a search filter or a DN pattern. In the case below, the user joe would have a full DN of uid=joe,ou=users,dc=mydomain,dc=net.

The search would be rooted at ou=groups,dc=mydomain,dc=net, looking for directory entries that include the attribute uniqueMember=uid=joe,ou=users,dc=mydomain,dc=net, which is the structure for the groupOfUniqueNames group standard.

The groupRoleAttributes is how the group/role name is extracted. For example, all entries that pass the filter will then have the cn (common name) attribute returned.

IF you want to use a username instead of a user DN for group membership, you can specify {1} instead of {0} for the groupSearchFilter parameter.

Source code

To see the internals (can be useful for debugging):

Fiat: LdapUserRolesProvider
Spring Auth Provider: LdapAuthenticationProviderConfigurer
Gate: LdapSsoConfig

Docs: Pipeline Permissions

Mon, 01 Jan 0001 00:00:00 +0000

You can use pipeline permissions as an alternative to manually managing Fiat Service Accounts .

Without pipeline permissions, a Spinnaker operator first has to create a Fiat Service account with the correct permissions. A user can then specify the service account as the RunAsUser per automated trigger. Pipeline permissions simplifies this flow – a user only has to specify the set of roles in the pipeline specification based on which a Fiat service account is automatically created and associated with the pipeline.

Enabling pipeline permissions

Pipeline permissions are disabled by default and can be enabled by setting the following flags:

For Orca, add the following to orca-local.yml

tasks:
  useManagedServiceAccounts: true
  ## Recommended to reduce duplicate service accounts by only creating unique service accounts by role set.  This drastically
  ## can improve spinnaker auth sync times by reducing the number of service accounts, particularly with limited sets
  ## of variable service accounts
  useSharedManagedServiceAccounts: true

For Deck, add the following to settings-local.js

window.spinnakerSettings.feature.managedServiceAccounts = true;

Using pipeline permissions

The permissions selector will show up automatically when an automated trigger is added in the pipeline configuration page in the UI. You can add any of the roles that you currently have. Once you add a role to the pipeline, only users who have all of the specified roles can edit the pipeline. This is similar to the behavior of Fiat service accounts .

Migrating from Fiat service accounts

Once pipeline permissions are enabled, the RunAsUser selector will be hidden from Deck. However, any previously configured triggers will continue to use the previously selected service account in order to maintain backwards compatibility. Newly added triggers will use the permissions specified. If you wish to use pipeline permissions for the older triggers and already have permissions specified, edit your pipeline JSON and remove the RunAsUser field from your trigger, or enable the automatic migration (see next section).

Automatic migration

Front50 can automatically migrate all pipelines from using Fiat Service Accounts to use Pipeline Permissions and managed service accounts. The migrator is disabled by default, and can be enabled by adding the following flag to front50-local.yml:

migrations:
  migrateToManagedServiceAccounts: true

This migration will migrate pipelines that have Fiat service accounts set to the new Pipeline Permissions. It will only run on pipelines where roles are not already present and runAsUser is set to a non-managed service account.

The migration job will automatically create the new managed service users, and the new service user will get the same permissions as the manual service user that it replaces.

If a pipeline has multiple triggers with different runAsUser fields set, the new managed service user will get all of the roles of the different manual service users (as you can only have one managed service user per pipeline). This can potentially remove some users ability to edit affected pipelines.

Docs: SAML

Mon, 01 Jan 0001 00:00:00 +0000

The SAML use case is a special one - it’s the only one where a user’s roles cannot be dynamically updated. This is because the user’s roles are sent in the initial authentication handshake between Gate and the SAML Identity Provider (IdP).

IdP Setup

To enable SAML roles, configure your IdP to include group membership in the assertion (not covered - some providers may not offer this option). By default, Gate looks for the memberOf attribute statement, but this can be reconfigured in Gate’s settings.

When Fiat is enabled, SAML groups are automatically pushed to Fiat upon user login and cannot be updated until the user needs to reauthenticate.

Troubleshooting

Docs: Service Accounts

Mon, 01 Jan 0001 00:00:00 +0000

Service Accounts enable the ability for automatically triggered pipelines to modify resources in protected accounts or applications. Practically speaking, this means that a Git commit could trigger a Jenkins build that could then kick off a pipeline to deploy the newly built image in your access-controlled QA environment. The pipeline would run utilizing the permissions of the service account. Service accounts are NOT authenticated accounts but abstractions around permissions for roles.

A simpler approach for many users is pipeline permissions which enable auto creation of service accounts on demand. This is here for those who do NOT want to allow service account creation and require very tight control over trigger execution permissions

Creating service accounts

Service accounts are persistent and configuration merely consists of giving it a name and a set of roles. Therefore, Front50 is the most logical place to configure a service account. There is no UI for creating service accounts at the moment.

Users with all the roles defined in the service account can grant a pipeline “Run as ” but only if the service account itself has EXECUTE access to that app. Users with EXECUTE access to the app can then run the pipeline with additional set of roles (e.g. access to a provider account or some other app).

FRONT50=http://front50.url:8080

curl -X POST \
  -H "Content-type: application/json" \
  -d '{ "name": "sekret-service-account@spinnaker-test.net", "memberOf": ["myApp-prod","myApp-qa"] }' \
  $FRONT50/serviceAccounts

Note: In the above command, myApp-prod and myApp-qa are roles, not application names.

You can see your new service account that just got created:

curl $FRONT50/serviceAccounts

A Fiat sync may be necessary for all affected users to pick up the changes:

FIAT=http://fiat.url:7003

curl -X POST $FIAT/roles/sync

Confirm the new service account has permissions to the resources that you think it should by querying Fiat:

$ curl $FIAT/authorize/myApp-svc-account

Service account roles

The roles you give this service account determine who has access to use it. In order to prevent a privilege escalation vulnerability, only users with every role the service account has may use it.

For example, if user “Batman” has roles foo, bar, and baz and service account “Alfred” has roles foo and bar, then “Batman” has access to use “Alfred” in his pipelines. However, user “Joker”, with role foo, does not have all of the roles “Alfred” has, so he cannot use it.

Using service accounts

With Fiat enabled, you should now see a “Run As User” option in your Trigger configuration. This list contains all of the service accounts you currently have access to.

Upon saving this pipeline, two authorization checks occur:

Does this user have access to this service account? (If using the UI, this should always be the case.)
Does this service account have access to this application?

At pipeline runtime, standard authorization checks against the account and application occur just as if it were a human user.

Deleting service accounts

To delete a service account, use the following DELETE endpoint in Front50:

# Service Account ID is the same as service account name with all lowercase
SERVICE_ACCOUNT_ID="sekret-service-account@spinnaker-test.net"
FRONT50=http://front50.url:8080
curl -X DELETE "$FRONT50/serviceAccounts/$SERVICE_ACCOUNT_ID"

Similar to service account creation, a Fiat sync (curl -X POST $FIAT/roles/sync ) might be necessary for the changes to be immediately reflected.

Docs: GitHub Teams

Mon, 01 Jan 0001 00:00:00 +0000

GitHub App Authentication (Recommended)

GitHub App authentication, available in releases after 2025.4.0, is the preferred method for connecting Spinnaker to GitHub. It offers significant advantages over Personal Access Tokens (PATs):

Higher Rate Limits: GitHub Apps have a rate limit of 15,000 requests per hour (vs 5,000 for PATs).
Enhanced Security: Uses short-lived tokens that are automatically refreshed, rather than long-lived static tokens.
Granular Permissions: Apps can be scoped to specific permissions.

Prerequisites

You have GitHub organization admin permissions to create and install the app.

1. Create a GitHub App

Navigate to your GitHub Organization Settings > Developer settings > GitHub Apps.
Click New GitHub App.
Set the following fields:
- GitHub App Name: e.g., spinnaker-fiat-auth.
- Homepage URL: Your Spinnaker URL (or placeholder).
- Callback URL: Your Spinnaker URL (or placeholder).
- Webhook: Uncheck “Active” (not needed for authorization).
Permissions:
- Organization Permissions > Members: Read-only
Click Create GitHub App.
Note the App ID.
Generate a Private key and save the .pem file.
Install App: Go to “Install App” in the sidebar and install it on your organization. Note the Installation ID from the URL (e.g., https://github.com/organizations/my-org/settings/installations/12345678 -> 12345678).
- Install at the organization level (not per-repo) so team membership lookups work for all repos.

GitHub App installation tokens are short-lived (1 hour) and Fiat caches them in memory with an early refresh buffer. They are never written to disk.
PATs configured with --accessToken are stored in Fiat configuration; rotate them periodically and handle them like any other long-lived secret.

Personal Access Token (Legacy)

If you cannot use a GitHub App, you can still use a Personal Access Token (PAT). Note that this has lower rate limits.

Under an administrator’s account, generate a new Personal Access Token from https://github.com/settings/tokens .
Give it a descriptive name such as “spinnaker-fiat.”
Select the read:org scope.
Click “Generate Token”

Configure Fiat

Add the following configuration to fiat-local.yml to have fiat load group membership from github:

auth:
  group-membership:
    service: github
    github:
      ## When to refresh group info
      membershipCacheTTLSeconds: 600
      ## 1000 github teams
      membershipCacheTeamsSize: 1000
      ## Defaults to 100
      paginationValue: 100 
      ## AUTO == Pick based upon what config is set and defaulting to GH Apps as first priority
      authMethod: AUTO 
      baseUrl: https://api.github.com/
      organization: my-org
      ## When using a PAT:
      accessToken: PAT 
      ## When using a GH App
      appId: 12345
      installationId: 67894
      privateKeyPath: encryptedFile:orVolumePath

The authMethod property controls which authentication method Spinnaker uses:

AUTO (Default): Automatically prefers GitHub App if app-id, installation-id, and private-key-path are configured. Falls back to PAT if App credentials are missing.
GITHUB_APP: Forces GitHub App authentication. The configuration fails if App credentials are not provided or invalid.
PAT: Forces Personal Access Token authentication. The configuration fails if access-token is not provided.