Authentication

Spinnaker’s authentication mechanism supports a variety of different login sources.

There are a lot of moving parts involved with getting authentication to work. This page describes the basics and tools that make setup easier to configure and test.

Introduction

There are three basic systems involved with Spinnaker’s authentication workflow: your identity provider, Gate, and Deck. The changes will primarily be made to either your identity provider or Gate. Deck itself will not require changes or updates, but it’s useful to understand how all three parts interact.

graph LR classDef default fill:#d8e8ec,stroke:#7a8288; linkStyle default stroke:#7a8288, stroke-width:2px, fill:none; gate(Gate) idp(IdentityProvider) deck(Deck/Browser) deck-->gate gate-->deck deck-->idp idp-->deck

  1. Deck: Spinnaker’s UI. Consists of a set of static HTML, JavaScript, and CSS files. Generally served from an Apache server, but there is nothing special about Apache that makes Deck work. Replace with your favorite HTTP(S) server if you’d like. The Javascript being an SPA Single Page Application is going to do the communication with your identity provider. Which IDP is determined by Gate.

  2. Gate: Spinnaker’s API Gateway. All traffic (including traffic generated from Deck) flows through Gate. It is the point at which authentication is confirmed and one point (of several) where authorization is enforced.

  3. Identity Provider: Your organization’s OAuth 2.0, SAML 2.0, or LDAP service. X.509 client certificates can be used in addition to any of these services, or used standalone.

Incognito mode

Incognito logo{:width="50px”}

Getting the authentication working rarely happens on the first try. Each login attempt during configuration (or development) causes a new session to be established in Gate’s session repository. Re-using these sessions is undesirable when testing configuration changes.

We highly recommend using Google Chrome’s Incognito mode when working with configuration changes.

  1. Open a new Incognito window.
  2. Navigate to your Spinnaker’s Deck endpoint.
  3. Observe behavior and make configuration change. Restart affected Spinnaker service.
  4. Close Incognito window.
  5. Repeat from step 1.

A common issue with Incognito windows is that they all share the same cookie jar. This means that when you want to test a new configuration change, you need to close all Incognito windows. Otherwise, the session cookie will not be deleted.

Available Options

  • Methods
    • OAuth 2.0/OIDC - The main examples are Google & GitHub endpoints.
    • SAML - Lots of examples on this with one of the most prevalent being Okta.
    • LDAP - This covers Active Directory and other LDAP servers, such as OpenLDAP.
    • X.509 - Often used for client or application communications. Can operate in conjunction with other authentication methods.

Next steps

Set up Authorization .

Learn how to configure Spinnaker to communicate over SSL .

LDAP

Spinnaker supports using LDAP for authentication.

OAuth 2.0

Use OAuth 2.0 to authenticate users and grant them access to Spinnaker.

SAML 2.0

Spinnaker supports using a SAML identity provider for single sign-on authentication.

X.509 Client Certificates

Spinnaker supports using x.509 certificates for authentication.

Last modified May 7, 2021: docs(migration): fix imgs and links (9a18ce6)