Authorization (RBAC) on Spinnaker

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.

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.

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.

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.

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.

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.