I've got a challenge in my workplace regarding a new security policy we've implemented. Our company has set up a Vault server to store all credentials securely, accessible via a REST service. While this service is supposed to handle security on its own, developers are expected to manage credential retrieval when needed. Specifically, credentials must be fetched either at startup or when required, and if they are invalid, the application must return an error while also attempting to fetch new credentials. However, the applications won't be notified when credentials change, which leads me to wonder how to integrate this approach with connection pools, particularly given our existing use of JDBC and JTA for AS400 connections, which currently get their credentials from environment variables. Have any of you worked with Java apps under similar constraints? I'd love to hear your experiences or any thoughts on how to tackle this scenario!
5 Answers
I don’t see a major problem with connection pools handling this. They should recover from network issues just fine, so adapting to credential changes shouldn't be too different. As long as old credentials stay valid for a short while, you could implement a smooth transition if your pool renews connections periodically.
Your requirements seem to align with what AWS Secrets Manager offers. Using this service helps avoid building something from scratch. If you're already on AWS, it's worth leveraging it instead of reinventing the wheel.
Good point! We do use AWS Secrets Manager for environment variables during deployment, but we're also looking at Hashicorp's Vault for a cloud-independent solution. I have limited influence over how the credential service is implemented, unfortunately.
I've been in a similar situation with a large bank. The solution was to create a custom DataSource that wraps the actual connection pool, like Hikari. You can override the password retrieval method to get the credentials from the Vault, which gives you control while still leveraging the connection pool. This could work well for your setup!
That's a smart approach! We also use Hikari with MyBatis in some areas, so I'll definitely keep this in mind.
This whole approach seems like it could create a single point of failure. If the Vault goes down, you’ll have a lot of systems struggling. This policy sounds like it needs a better risk analysis. There should be some leeway, like overlapping valid credentials, to avoid completely shutting down the services during updates.
I share those concerns! The management insists on this design to reduce developer dependency, which seems a bit risky to me.
At my company, we rotate credentials every 30 minutes. I've implemented a custom provider that fetches the latest credentials at intervals. It's a bit tricky to manage live updates without interrupting ongoing transactions, though.
That's interesting! How do you ensure ongoing connections don’t break when the credentials change?
That makes sense in theory, but I'm worried about how to ensure a connection pool transitions smoothly between old and new credentials mid-operation without disrupting services.