4 ms·

We are considering this at work, but there seems to be a problem. The secrets only last for a fixed amount of time. How do people handle refreshing secrets on

We are considering this at work, but there seems to be a problem. The secrets only last for a fixed amount of time. How do people handle refreshing secrets on servers which maintain a connection to a database once their creds expire?

lstamour 10y ago
Sounds like it might be database or implementation-specific. From quick Googling I found https://groups.google.com/d/msg/vault-tool/6jhwtqkfpA8/IK2_HcNO-bYJ https://groups.google.com/d/msg/vault-tool/6jhwtqkfpA8/IK2_H... and http://stackoverflow.com/questions/38579168/spring-boot-jdbc-with-password-lease-renew-as-in-vault http://stackoverflow.com/questions/38579168/spring-boot-jdbc... -- see also, periodic tokens: https://github.com/hashicorp/vault/blob/master/website/source/docs/concepts/tokens.html.md#periodic-tokens https://github.com/hashicorp/vault/blob/master/website/sourc... I look forward to other answers though, if anyone's currently set this up. I haven't used it yet myself, but I've been considering it.
brazzledazzle 10y ago
The idea is that Vault creates/deletes/rotates the credentials that are used so the timeframe for exposure is limited. If your application can't re-connect to a database and drain the prior connection pool (or remove itself from a load balancer while restarting–whatever works for you) the credentials have to be long lived. In that situation I would check out periodic tokens[0] since they live as long as they're renewed within the TTL. 0. https://www.vaultproject.io/docs/concepts/tokens.html#periodic-tokens https://www.vaultproject.io/docs/concepts/tokens.html#period...
wernerb 10y ago
You could rotate the key (make available the new secret) before expiring the old. During that time (which can be even a few hours) you typically reload your application to use the new credential. If you are able to change your application's code, you could integrate with vault's API directly which is the most clean solution. If you are unable, you can use [consul-template](https://github.com/hashicorp/consul-template https://github.com/hashicorp/consul-template) or [envconsul](https://github.com/hashicorp/envconsul https://github.com/hashicorp/envconsul) to securely introduce your secret which would entail reloading/restarting your application.
- tedmiston 10y ago
  I think rotating with a little short-term redundancy is the simplest solution. That's what I've used myself too.
zie 10y ago
if you mean the generic backend(a place to store secrets), they do not last a fixed amount of time, they are there forever.. there is a TTL, but vault does not erase anything that outlives it's TTL. Locally we just touch the TTL whenever we access it, in case someday the TTL's are followed and secrets get erased. TOKENS however do get killed at the end of their TTL. But you can renew tokens forever if you allow for that.
empath75 10y ago
Consul-template.

lstamour 10y ago

Sounds like it might be database or implementation-specific. From quick Googling I found https://groups.google.com/d/msg/vault-tool/6jhwtqkfpA8/IK2_HcNO-bYJ https://groups.google.com/d/msg/vault-tool/6jhwtqkfpA8/IK2_H... and http://stackoverflow.com/questions/38579168/spring-boot-jdbc-with-password-lease-renew-as-in-vault http://stackoverflow.com/questions/38579168/spring-boot-jdbc... -- see also, periodic tokens: https://github.com/hashicorp/vault/blob/master/website/source/docs/concepts/tokens.html.md#periodic-tokens https://github.com/hashicorp/vault/blob/master/website/sourc... I look forward to other answers though, if anyone's currently set this up. I haven't used it yet myself, but I've been considering it.

brazzledazzle 10y ago

The idea is that Vault creates/deletes/rotates the credentials that are used so the timeframe for exposure is limited. If your application can't re-connect to a database and drain the prior connection pool (or remove itself from a load balancer while restarting–whatever works for you) the credentials have to be long lived. In that situation I would check out periodic tokens[0] since they live as long as they're renewed within the TTL. 0. https://www.vaultproject.io/docs/concepts/tokens.html#periodic-tokens https://www.vaultproject.io/docs/concepts/tokens.html#period...

wernerb 10y ago

You could rotate the key (make available the new secret) before expiring the old. During that time (which can be even a few hours) you typically reload your application to use the new credential. If you are able to change your application's code, you could integrate with vault's API directly which is the most clean solution. If you are unable, you can use [consul-template](https://github.com/hashicorp/consul-template https://github.com/hashicorp/consul-template) or [envconsul](https://github.com/hashicorp/envconsul https://github.com/hashicorp/envconsul) to securely introduce your secret which would entail reloading/restarting your application.

tedmiston 10y ago
I think rotating with a little short-term redundancy is the simplest solution. That's what I've used myself too.

zie 10y ago

if you mean the generic backend(a place to store secrets), they do not last a fixed amount of time, they are there forever.. there is a TTL, but vault does not erase anything that outlives it's TTL. Locally we just touch the TTL whenever we access it, in case someday the TTL's are followed and secrets get erased. TOKENS however do get killed at the end of their TTL. But you can renew tokens forever if you allow for that.

empath75 10y ago

Consul-template.