Storing vault read token securely

Question

I have PCF spring boot application which needs to access the vault server to get the credentials to create datasource during startup. Right now we are hard coding the app role id and secret id in the spring boot application . Is there a best practices in storing this secret id without exposing explicitly (like injecting during startup)

Answer 1

This is basically the "zero-secret" problem. Moving all your secrets off to a secret storage service is a great way to start securing your systems, but doesn't really gain you much if you then store the access code to access your secret service directly in your code base.

Authentication Methods

The best answer is that a good secret-service will give you ways of logging in without needing a secret in the first place. You are using approle, and that basically just lets you login to Vault using the equivalent of an API ID and API Key. This is really meant as a catch all authentication method to use in cases where you can't make anything else work, but it isn't the best because then you have just exchanged one secret storage problem for a more centralized one.

If you are running on a major cloud provider (although from comments, it seems like you aren't) then you can use IAM Auth with Vault. This will allow you to authenticate to Vault on the basis of an IAM role attached to your infrastructure, allowing you to authenticate without any secrets in your code base/deployment system at all. Vault will issue you a token as a result of the successful login and then you can pass this into Spring as an environment variable.

Another good option is JWT auth. If you have an "authority" somewhere that can issue you a JWT and publishes its public key somewhere public, you can use that JWT to login to vault via JWT/OIDC auth. A good example of this is Gitlab - Gitlab provides a signed JWT for their public runners and publishes their public key, so you can use JWT auth with Vault to authenticate without having to provide any secrets at all.

I'm not familiar with PCF, so I'm not sure what options might work best for you there, but the key is to try to find an option that allows you to login without having to store a secret/access code anywhere. This is true regardless of what secret service you are using and what infrastructure you are running on.

Answer 2

There are numerous things that you could do, depending on whether the host is permanent or if it's under development and might be moved, etc. One way some people store this information during development is simply putting them into environment variables that the application reads. Yes, other applications can potentially read these, but I don't think it's likely for dumb malware to be able to abuse them.

Another solution is to just pass the creds in through command line arguments. This is potentially more work, but other applications and users won't be able to read this as easily (they can of course look through your command line history), and if you decide that it just isn't worth the effort later, you could write a script to run the application with the hard coded creds.

Another idea based off this answer is to have the secret stored on some external hardware that the software could read from. If you're really serious, you could put the secret in an encrypted file that would require a key file or a Yubikey to decrypt. The application would then just read from this file. Obviously, file permissions need to be properly set here so that only the user running the application can read this file.

You could possibly encrypt the secret and store this inside the application, and provide a key through the command line arguments to decrypt it in memory. Whether this is any better than the other solutions is debatable. It all depends on what your needs are and what you're trying to protect the credentials from.