Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation
secrets-as-a-service.com
Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation
1–6 of 6 posts
Re: Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation
#2Author here. Happy to answer any questions or hear any feedback about this post.
Re: Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation
#3Thanks 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.
Re: Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation
#4Thanks 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…
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
Re: Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation
#5Thanks 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…
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…
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.
Re: Hashicorp Vault max_ttl killed my Spring app: Handling database creds rotation
#6Earlier quoted context omitted.
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…
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.
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.