Hacker News Reader

Comment by tompic823 | Hacker News Reader

Great point about dynamic secrets. This is an area we currently don't address, but it is definitely on our roadmap. There is a segment of the market for which dynamic secrets are an absolute requirement and we fully acknowledge that.

View on HN

Just out of curiosity - what do people use dynamic secrets for? What is a "dynamic" secret anyway?

At our company, we use vault to generate and cycle short-lived database credentials and tls certs. Our RPC services use the certs to encrypt their traffic amongst each other, and also to enforce RBAC (since the certs are traceable, via vault, to a service or individual's identity).

"Dynamic" secrets imply that rotation is automated and frequent, and that there are no "blessed" certs, but rather that all certs/keys are generated in exchange for a successful identity assertion.

For example, if I can prove that I am LDAP user gen220, who belongs to group db-x-developer, I have earned the right to request a credential for connecting to db-x, which expires some arbitrary time before my identity-assertion expires.

A simple example that we use them for is for dynamic database credentials. So you no longer define a static username/password. You request the access/credentials from vault as you need them.

how does that actually work? Vault has the user/password, and then acts as a gateway to the db?

IIRC, Vault has plugins with GRANT access to your database, and rotates your passwords automatically. So it is able to create new users when access is requested, and to rotate passwords if needed.

https://www.vaultproject.io/docs/secrets/databases/mysql-mar...

It looks like this https://www.nomadproject.io/docs/integrations/vault-integrat...

It's incredibly simple, and a breeze to use.

``` job "vault" { group "demo" { task "task" { vault { policies = ["database"] } template { env = true data = <<EOF {{ with secret "database/creds/production" }} DB_USERNAME={{.Data.username}} DB_PASSWORD={{.Data.password}} {{ end }} EOF } } } } ```

edit: thanks HN formatting

with this setup, Vault will create a new database user based on the configuration you set (read-only for some services, for example), and will attach a time-to-live to those credentials; as long as the application is using them, it will renew the TTL. When an application is killed, or scaling happens, etc, and the application instance isn't using those specific credentials, Vault will clean up and remove the unused account cleanly

Can do all sorts of great things with this; for example TLS (ssl) certificate renewals, etc, as the certificate expiry IS the TTL; when a certificate needs to be renewed it can happen automatically and your application can receive any signal you choose (SIGHUP, for example)

Fascinating! Thanks for sharing, I had no idea this was possible.

I guess dynamic secrets are too "ftp" for Doppler, eh?

You lost the entire audience who have actually used Vault before when you claimed it was too complex for your team to understand.. Why would I trust a company staffed with a crew that can't even understand the tools they are trying to compete with

Reply on news.ycombinator.com