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)

  • As in, in the code itself? Because using a secrets solution doesn't help you if the credentials for your secrets solution are stored in the code repository where anyone can see them and, therefore, login to your secrets storage Dec 15, 2020 at 9:54

2 Answers 2


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.


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.

  • 1
    Thanks , we are seriously considering vault in PCF but all boils down to one question , where we store this vault read token or like you suggested if we use encryption file where to store the encryption key for decryption. Does it make sense ?
    – adorearun
    Mar 26, 2019 at 1:56
  • 1
    Yeah, I understand. I've never actually used what you're using, but if you want to actually store the token (not use environment variables or the command line arguments) then its a little more difficult. If you want to encrypt it and decrypt it with a key of some kind then you could probably get away with putting the file next to your application. I don't know much about how you're using this or what your concerns are so I can't really give you great advice. Did you try researching this question? There are a lot of other similar threads and this might get marked as a repost/duplicate
    – Pheric
    Mar 26, 2019 at 2:01
  • Sorry for not explaining it properly , exposing encryption key / vault read token either in our version control system (GIT) or as env variable. Is there a way to secure it ? I have researched but in my use case we run our application in Pivotal Cloud Foundry (PCF) so most answers were not relevant.Looking for a tool to inject the properties while server startup.
    – adorearun
    Mar 26, 2019 at 2:12
  • @adorearun alright. I don't know what to tell you then. I hope you find a solution soon. Sorry I couldn't solve your problem
    – Pheric
    Mar 26, 2019 at 2:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .