Securing Databases with Dynamic Credentials and HashiCorp Vault

Applications are always going to be leaky intstances where attackers will often find creative ways to obtain credentials and other secrets (API keys, certificates, etc.). Managing secrets in a central repository is a great first step toward mitigating threats, but it's not enough.

Because generating certificates is a slow, burdensome process, many organizations will maintain certificates that are valid for years, floating around their systems in plaintext, without any means to revoke them easily if their data is breached.

Frequent credential rotation (Dynamic Secrets) is the best protection against the majority of network intrusions where attackers often have valid credentials to move towards sensitive data. But how do you make rotation simple and automated?

In this Solutions Engineering Hangout session, Thomas Kula, a solutions engineer at HashiCorp, will demo how to use HashiCorp Vault to deliver dynamic database credentials in an easy, automated manner. He'll also discuss why dynamic secrets make sense as more architectures become service oriented.

Outline

0:00 — Intro to dynamic secrets and why you should use them

5:50 — Demo: Securing databases with dynamic credentials with Vault - (GitHub Repo)

24:25 — Q&A

Q&A

• What databases does Vault work with besides MySQL?
• How many requests can a single Vault server handle?
• How does Vault know the application should have access to the specific policy you assign to it?
• If I set the TTL (Time-to-live) of a secret to 30 days, can multiple read calls get the same credential for those 30 days or will it always be a new credential generated through the SQL query provided?
• Does Vault ‘maintain state’ as in, if an account is removed manually in a DB, will it recreate it? Also, the other side, if Vault gets restarted (assuming unclean, no-HA scenario) will it remember the state of the accounts it has created and be able to remove accounts from the DB when they expire?
• We’re considering Kubernetes and Vault integration. Can you provide best practices related that? Would you run Vault within the cluster that’s using it? Or would you rather provision it elsewhere?
• Where does Vault store data?
• Are the credentials you provided to Vault at the beginning to connect to the database also dynamic?
• Does Vault change its credentials for "Vault Agent"?
• Is it possible to set up dynamic database credentials in the UI or is it only possible to set this up in the CLI?

Slides