
Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation - usr42
https://secrets-as-a-service.com/posts/hashicorp-vault/spring-boot-max_ttl/
======
tonnydan
Thanks a lot for the prestigious blog post to resolve my (and someone else's)
question in Github. The options of 1 to 3 may resolve the question in some
technically practical way, but I'm afraid it is hard to be used in production
environment. Especially, the option 3 causes services to be rebooted out of
scheduled operation plans, which will impact on the SLA eventually. I warmly
look forward to your next blog post of option 4 which may be more complex but
more practical.

~~~
usr42
I totally agree with your analysis. All the options only work if you have the
right constraints and prerequisites. Option three can be a valid use-case if
you already have multiple (stateless) replications of your application running
in parallel. For instance in a typical microservice architecture this is
usually the case. A restart of one of the replications _should_ then not
impact the SLA. In a real-life scenario it could of course be a bit more
complicated. If all the replications where started at roughly the same time,
the expiration could still result in an outage.

The next blog post has more restricted prerequisites (HikariCP as connection
pool, which only supports JDBC), but solves the problem more gracefully. I
hope I can finish this blog post soon.

A repository with the example code is already existing. If you are interested,
here is the link: [https://github.com/usr42/spring-vault-database-
rotate](https://github.com/usr42/spring-vault-database-rotate)

~~~
tonnydan
It is correct that one service application down in a services' cluster would
not cause the service itself be offline, but the capability of processing
requests will be impact. That is what I said which will impact on the SLA. And
also, the reboot may not be predicted, which might be the fatal problem.

~~~
usr42
The reboot option is definitively not the right choice for all use cases but
could be an option, depending on your constraints. At least it is still better
then just not handling the expiration at all.

I think the follow-up post fits your needs better because no restart and so no
downtime is needed. Hopefully I can finish it the next days.

------
usr42
Author here. Happy to answer any questions or hear any feedback about this
post.

