Secrets Management

Secrets management is the practice of keeping credentials out of the places they naturally accumulate — config files, CI variables, container images, someone's shell history — and delivering them to workloads in a form that can be scoped, audited and revoked. The failure mode it exists to prevent is not usually a clever attack. It is a key that was copied somewhere convenient years ago, is still valid, and that nobody can now say who holds.

The discipline splits into two problems that get conflated. The first is storage: where the value lives and who may read it. The second, and harder one, is introduction — how a workload proves who it is before it holds any credential at all. That is the secret-zero problem, and the modern answer is to lean on an identity the platform already asserts: a Kubernetes service account, an AWS IAM role, a GitHub Actions OIDC token. Solve introduction well and the long-lived key disappears entirely rather than merely moving somewhere safer.

This track follows the whole chain. Fundamentals first — secret sprawl, dynamic versus static secrets, leases and revocation, envelope encryption and crypto-shredding. Then HashiCorp Vault in depth, structured around the Vault Associate (003) exam objectives: auth methods and identity, policy paths and capabilities, service versus batch tokens, secrets engines from KV v2 to dynamic database credentials and PKI, transit as encryption as a service, seal and unseal with Shamir shares, replication, and the Vault Agent and Secrets Operator. Then the surrounding ecosystem: Sealed Secrets, SOPS and External Secrets Operator for GitOps, cert-manager for certificates, and the cloud and CI end where GitHub Actions can reach a cloud account with no stored key at all.