Can you keep a secret?
summary
Demo shows a misconfigured Hashicorp Vault setup where a Kubernetes service account uses its JWT to get a Vault client token and an overly broad policy (secret/) lets an attacker read, write and permanently destroy secrets. Reproducible steps include exporting env vars, enabling the Kubernetes auth method, binding a role to a service account and abusing wildcard policy paths. Takeaways: do an inventory, apply principle of least privilege with explicit paths, dynamic credential rotation* shrinks blast radius, and automate pen testing and CI checks to catch secret sprawl.
AI-written summary · about
chapters (15)
- 0:00Start
- 2:43meet those regulator requirements
- 3:01prevent those lateral moves within your network
- 9:08give the bare minimum of privileges
- 11:15write the vault policy
- 12:40use the kubernetes jwat token to authenticate
- 13:29simulate an attack in about five minutes
- 14:14set the vault address
- 14:43using a curl request with the cube token
- 17:00delete that initial database connection
- 17:44destroy your secrets
- 18:47attach the correct policies
- 19:26know your requirements
- 19:48creating the policies
- 22:29the credential rotation
related talks
23mUsing Hashicorp Vault in Kubernetes Clusters
29mSecuring Secrets in K8s Environments
38mKeeping Secrets - A Practical Approach to Managing Credentials
31mVault and Secret Management in Kubernetes
49mManaging Secrets in a Kubernetes Cluster with Hashicorp Vault
08mKubernetes Secret Management The Right Way With Vault
28mHow to Store Secrets—and When Do You Need Them—in HashiCorp Vault
43mSecret Management with Hashicorp's Vault