
Spinnaker
Protect access to Spinnaker deployment services as upstream web applications.
Overview
Spinnaker is a continuous delivery platform. Its Deck web interface and Gate API are separate services with separate endpoints. A useful access design must account for both public components.
Spinnaker can expose sensitive application data or administrative functions. A Pomerium route adds identity-aware policy before a user reaches the selected endpoint while the service keeps its own detailed permissions.
Pomerium controls who can establish the selected route to Spinnaker. Spinnaker remains responsible for its application, protocol, data, and service-level permissions.
How it works
Create a Pomerium HTTPS route for the selected private HTTP endpoint. Configure the application public URL and trusted proxy settings for the Pomerium origin.
Keep application authentication and granular authorization active when the service needs them. Give API and automation clients a reviewed noninteractive authentication path.
Create the required route or routes for Deck and Gate. Configure each public URL and test browser API calls, callbacks, and automation independently.
Example
Release engineers use a Pomerium route for Deck. Deck calls Gate through its configured public API origin. Spinnaker keeps Fiat and Gate authentication and authorization controls.
Considerations
- A route to Deck alone is incomplete when the browser or tools must reach Gate.
- Automation and command-line clients need compatible noninteractive credentials. Keep Fiat and service security active.
