-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic Credentials? #197
Comments
Hi @TJM - feel free to PR this :D |
;) For now, we are using Vault Agent (injector) and writing the credentials to a file in tmpfs, which is read by the node app whenever it needs to authenticate. I feel like the integration could still be made better, but its their app :) |
Hey @TJM |
@aviadhahami - Instead of using this SDK to integrate to vault directly, we are using Vault Agent as a sidecar container, which handles the authentication (kube auth) and maintaining the lease for that token and the lease for the mongoDB credentials. The Vault Agent just places the credentials into a "file" ( |
To ensure I understand, you'd like this lib to handle credential rotations throughout its lifespan. is this correct? |
Yes, we would like this SDK to handle dynamic credentials. Right now it handles static credentials, but not dynamic ones. The Vault agent solution is a workaround. Here is an example of the vault setup: https://developer.hashicorp.com/vault/tutorials/db-credentials/database-secrets ... admittedly we are using Atlas MongoDB, but for the purposes of the vault SDK, the type of credential doesn't matter much. In this tutorial setup, the application logs in and retrieves a database password (GET /database/creds/readonly). That works and this SDK handles that fine, but after 1h, those credentials will be expired, unless the application renews the lease for the credential. Usually, the lease would be renewed at about 75-85% of its expiration(~45-51m). That will keep the current set of credentials from being expired by the Vault server. After 23 hours, it would be approaching the "max_ttl" value of 24h, so when it tries to renew the lease it will get a "warning" from Vault saying that it could not renew for an hour, and letting it know the remaining time... Example:
Now, as we all know, it will not possibly come out exact like that. Each renewal request will take some time, and there should probably be a little bit of randomness sprinkled in to prevent a "thundering herd" on renewals, but on the last renewal when there is not 60m left of available TTL, it will renew up to the max_ttl and return a warning that it could not renew the lease for the full time, and tell how long it is valid for. At this point, it should retrieve a new credential by re-issuing the GET request for the credentials and starting the whole process again. Ideally, there will be a small amount of overlap when both sets of credentials are valid, and the SDK can offer a mechanism to do a "callback" (?) to let the application know that it needs to reconnect to the database (refresh the pool, whatever). Additionally, this same functionality will need to be used to maintain the "token" which is returned after authentication. It also has a lease, and if that token expires, all credentials associated to it will also expire. I would highly recommend taking a look at the vault agent code. I know its not the same language, but it already does this, and can offer an algorithm at least. Additionally, they probably are aware of things that I did not cover above. :) ~tommy |
Hey @TJM ! I do have limited amount of time tho, so I am not sure when I'll be able to attend this |
We have a need to use dynamic credentials (example: TTL: 1h; MAX_TTL: 24h) in a nodejs application. This library appear to provide access to static credentials, but it does not appear to support dynamic credentials. Please correct me if I am wrong (as I am certainly not a developer)...
If the authentication token or credential lease is not maintained, then Vault will revoke the credentials to the leased credential, in this case MongoDB.
Additionally, when we hit the "max" TTL, the authentication credential will need to be replaced, and there didn't appear to be any sort of "callback" mechanism to notify the rest of the application (db pool?)
Thanks,
Tommy
The text was updated successfully, but these errors were encountered: