Authorization

Much like authentication, Spinnaker allows for a variety of pluggable authorization mechanisms. This page shows how to setup and configure Fiat, Spinnaker’s authorization microservice.

Model and features

Fiat’s authorization model is a whitelist that is open by default. In other words, when a resource does not define who is allowed to access it, it is considered unrestricted.

With Fiat, you can…

• Restrict access to specific accounts.
• Restrict access to specific applications.
• Run pipelines using automated triggers against access-controlled applications.
• Use and periodically update user roles from a backing role provider.

Requirements

• Authentication successfully setup in Gate.

• Configured Front50 to use S3 or Google Cloud Storage (GCS) as the backing storage mechanism for persistent application configurations.

• An external role provider from one of the following:
  • Google Groups via a G Suite Account
    • With access to the G Suite Admin console
  • GitHub Team
  • LDAP server
  • SAML Identity Provider (IdP) that includes groups in the assertion

    SAML roles are fixed at login time, and cannot be changed until the user needs to reauthenticate.

• Enable the authorization feature.

• Patience—there are a lot of small details that must be just right with anything related to authentication and authorization.

• (Highly Suggested) All Spinnaker component microservices are either:

  • Firewalled off as a collective group, or:

    

  • Use mutual TLS authentication:

    

Restrictable resources

Accounts and applications access control can be confusing unless you understand the core relationship: accounts can contain multiple applications, and applications can span multiple accounts.

Accounts

In the dark ages (before Fiat), only accounts could be restricted. Because Clouddriver is the source of truth for accounts, Fiat reaches out to Clouddriver to gather the list of available accounts.

There are two types of access restrictions to an account, READ and WRITE. Users must have at least one READ permission of an account to view the account’s cloud resources, and at least one WRITE permission to make changes to the resources.

These halyard commands manage the READ and WRITE permissions.

PROVIDER= # Your cloud provider

hal config provider $PROVIDER account edit $ACCOUNT \
  --add-read-permission role1 \ # Adds a READ permission
  --add-write-permission role2 \ # Adds a WRITE permission
  --remove-read-permission role3 \ # Removes a READ permission
  --remove-write-permission role4 # Removes a WRITE permission

# Alternatively, you can overwrite the whole read or write list, comma delimited.
hal config provider $PROVIDER account edit $ACCOUNT \
  --read-permissions role1,role2,role3 \
  --write-permissions role1,role2,role3

(Deprecated) requiredGroupMembership is the old way to add access restrictions to an account. This method does not distinguish between READ and WRITE - users with access will have both.

Applications

Before Spinnaker 1.14, there were two types of restrictions to an application READ and WRITE. In the 1.14 release, a new permission type called EXECUTE was added. For any new applications, the permission required to trigger pipelines changes from groups with READ access to those with EXECUTE access.

To maintain backward compatibility for existing applications, groups with READ access will implicitly get EXECUTE access. There are two ways to change this behavior:

• Modify the application config in the UI to explicitly add EXECUTE permissions to a group for an application:

• Flip the default behavior across all applications to only grant WRITE users implicit EXECUTE access by setting the following property in fiat-local.yml:

  fiat.executeFallback: 'WRITE'

Unrestricted accounts and applications

It’s important to understand what may happen if you leave either an account or application without any configured permissions.

• If an account is unrestricted, any user with access to Spinnaker can deploy a new application to that account.
• If an application is unrestricted, any user with access to Spinnaker can deploy that application into a different account. They may also be able to see basic information like instance names and counts within server groups.

Effects of restrictions

Because of the new access restrictions, https://localhost:9000/#/applications should no longer list applications that have been restricted. Even navigating to the previously accessible page should be denied:

Automated pipeline triggers

A popular feature in Spinnaker is the ability to run pipelines automatically based on a triggering event, such as a git push or a Jenkins build completing. When pipelines run against accounts and applications that are protected, it is necessary to configure them with enough permissions to access those protected resources. This can be done in two ways:

• Using Pipeline Permissions
• Using a Fiat service account

Role providers

To configure an external role provider, follow one of the instructions below:

• Google Groups with a G Suite account
• GitHub Teams
• LDAP Groups
• SAML Groups