Do's and Don'ts for Securing and Governing your Spinnaker Environment
summary
Spinnaker must be treated as core infrastructure: enforce DR, avoid pulling artifacts from public Docker Hub or unencrypted S3, and tag artifacts with immutable IDs so deployments reference known builds. Use a secrets manager—Vault, KMS, or AWS Secrets Manager—never hardcode env files or dot M files, and require webhook secrets. Centralize identity and map groups into Fiat—push IDP groups into Spinnaker—and enforce pipeline rules with a policy engine (Open Policy Agent examples presented).
AI-written summary · about
chapters (12)
- 0:00Introduction and context
- 1:05Speaker introductions
- 2:50Spinnaker's power and complexity
- 4:36Separating CI and CD
- 6:45Artifact security best practices
- 9:18Webhook security and disaster recovery
- 10:44Spinnaker's security out of the box
- 12:08Q&A on secrets management
- 13:41Secrets management approaches
- 15:47Identity provider integration
- 16:50Policy enforcement for governance
- 18:46Contact information and wrap-up
related talks
08mAutomated & Immutable Spinnaker Deployments with Security...
30mSecrets Management with Spinnaker
23mBuild a Spinnaker pipeline in highly regulated bank environment
19mSpinnaker Deployments on Kubernetes from a Security Perspective
26mVault integration for app delivery in Spinnaker: best practices & lessons
29mHardening Spinnaker Pipelines
15mSecuring your Deployments using a Policy Driven Approach
39mControlled Mayhem With Cloud Native Security Pipelines