Authentication & Authorization on Spinnaker

Authentication Architecture

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

Authentication

There are three basic players in Spinnaker’s authentication workflow:

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

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.
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.

Authorization Architecture

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

Ingress

Ingress involves the following components:

Clouddriver.
Front50 to query apps and service accounts.
Gate signs users in with externally provided roles (e.g. OpenID Connect, SAML). These roles are then merged with provider sourced roles (if any), tagged with the EXTERNAL source, and cached in Redis.
Igor gets the list of build systems and roles required to access them.

Egress

Egress involves the following components:

Redis stores computed roles, default permissions, and roles from external systems.
Clouddriver gets known accounts.
Front50 gets known apps.

Scaling

Fiat can be scaled by adding replicas. fiat.writeMode.enabled dictates if the Fiat instance will try to sync roles. Fiat instances coordinate around locks (in Redis) to ensure that only one instance synchronizes roles at a time.