Secrets Management with Spinnaker
summary
Claims that Spinnaker can enable GitOps for Spinnaker config by referencing secrets in external stores instead of checking plaintext into repos. Implements a concrete format like encrypted!s3!us-west-2!bucket/path[:key] and supports S3 and GCS plus Vault-style references. Halyard used to decrypt and write files but now services decrypt at runtime and keep secrets in memory only. Demo copies kubeconfig to S3, updates Halyard config, runs hal deploy and sees Front50 reference the secret with no plaintext on disk. Missing token refresh and wider backing‑store/KMS support.
AI-written summary · about
chapters (12)
- 0:00Intro
- 0:16What are secrets
- 1:20Motivation
- 2:07GitOps
- 4:31Before Secrets Management
- 7:44How it works
- 9:13Secret Format
- 10:20S3 Example
- 20:36Future enhancements
- 21:33Frequently asked questions
- 23:14Spring Cloud Config Server
- 23:46Questions
related talks
26mVault integration for app delivery in Spinnaker: best practices & lessons
19mDo's and Don'ts for Securing and Governing your Spinnaker Environment
19mSpinnaker @ Upside: Getting Started, Establishing Culture & Deploying Microservices with Confidence
24mCan You Keep a Secret? On Secret Management in Kubernetes
26mSecret Management in Kubernetes: The GitOps Way - Benjamin Ritter
39mManaging and securing Kubernetes secrets - Simon Pearce
29m100,000 Different Ways to Manage Secrets in GitOps
46mSecuring Secrets in the GitOps era