Kubernetes Secrets with KMS-backed etcd encryption (covered in M3 Lesson 18) address the at-rest confidentiality of credentials, but they do not solve several other critical secrets management problems: rotation (changing a credential without application downtime), auditability (who accessed which credential at what time), dynamic secrets (generating per-request database credentials that expire automatically), and multi-cloud credential federation (accessing AWS, GCP, or Azure services without storing long-lived cloud credentials in Kubernetes). HashiCorp Vault addresses rotation, auditability, and dynamic secrets through a centralised secrets management system with a time-bounded lease model. AWS IRSA (IAM Roles for Service Accounts) and GCP Workload Identity address cloud credential federation through OIDC token exchange, eliminating long-lived static credentials entirely. Together, these patterns implement the complete secrets management stack that Kubernetes Secrets alone cannot provide.
25 minintermediate
Advanced secrets management — Vault, IRSA and Workload Identity patterns
Analogy🏏Cricket
🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.
Lesson 26 of 33
0% complete