Dynamic Database Credentials
summary
Vault issues short‑lived PostgreSQL accounts on demand, creates GRANTs, and revokes them with a PG terminate when leases expire so credentials are tied to a machine heartbeat. Implementation uses Vault + PostgreSQL secret backend, Consul preferred as storage, and tools like consul-template heartbeating or Fabio for routing. Initialization uses Shamir unseal with 5 keys and threshold 2. Leases default to 1 hour, renew up to 24 hours, and credentials are capped at max 30 days; the system works for automated rotation and fast revocation.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:43Vault Manages Secure Information
- 1:25Operational Concern: Loss Aversion
- 2:17Security is an Operational Concern
- 3:43Types of Security Risk
- 5:40Benefits of Low Friction Security
- 7:25Sticking Points
- 8:45Keys to the Kingdom
- 9:32Meatspace Operational Concerns
- 10:16Why not use PostgreSQL for secrets?
- 10:46Embraced Requirements
- 13:41Secure like a Bank...
- 13:51Secrets Lifecycle in Dynamic Environments
- 14:15Vault Architecture
- 15:09Glossary
- 18:59Meatspace Integration
- 21:52Hypothetical Model
- 37:20Integrations: consul-template
- 39:42Integrations: fabio
- 40:22Initial Secret Placement
- 48:54How 'bout that API?
related talks
44mWho's managing the credentials for your database?
27mWho's managing the credential for your data infrastructure?
32mThe End of Shared Passwords with Vault and Boundary
51mIntroduction to Vault
38mHow To Secure Your MicroServices
44mSecret Management with Hashicorp's Vault
18mForget About DB Credentials with Terraform, Vault and Kubernetes
27mStop the (Password) Insanity! - Managing Credentials with HashiCorp Vault