AppRole response wrapping without trusted orchestrator in between


I am trying to figure out to how to overcome the so called ‘secret-zero’ problem in our environment.

Our application is calling Vault on an ad-hoc basis: whenever application’s API endpoint is called which needs to do an operation that requires some secrets fetched from Vault - it authenticates to Vault and gets the secrets it requires.

Right now authentication is done using static tokens embedded in environment files.
I would like to move to the AppRole authentication with response wrapping as all of the guides suggest. (Since just replacing the token with AppRole role-id and secret-id creds in environment vars is essentialy not improving security at all)

The problem with response wrapping is that with our setup we don’t have a so called “trusted orchestrator” which could pull the wrapped token and deliver it to the application - this app doesn’t use a full pipeline which could leverage something like Jenkins let’s say (I.E. Jenkins pulls wrapped tokens and hands it off to a runner which spins up an instance of the application).

My only idea was writing a custom script/app that would act as a “Vault proxy” to do the token wrapping and delivery to the application. The app would call this custom “proxy” and get the wrapped token whenever needed. But I am afraid that this can be a bad idea, since I might introduce some more vulnerabilities with the custom proxy app that I am unaware off.

So the question is - how would I go about implementing AppRole response wrapping in this environment? Which trusted system are you guys using for response wrapping?


I would treat any guide that suggests doing this with a healthy degree of scepticism. I am not convinced AppRole response wrapping is ever actually useful.

Doesn’t that just move the “secret zero” problem to the proxy?

It would be better explaining your environment and what you want to achieve, rather than starting from the assumption that AppRole response wrapping is the answer.

Most of the guides I am referring to here are from the official Hashicorp Vault guides. if you don’t mind on elaborating more - why do you say that it’s not actually useful?
The reason why I am looking into it is because Vault is suggesting it under every automation/application authentication to Vault guide, as the most hardened, go-to solution.

In my understanding the proxy wouldn’t have the “ultimate secret” to access secrets from the Vault. It will only store a token to get a wrapped secret-ID token for a specific role. It won’t be able to unwrap the token, nor it will have what is required to actually get secrets from the Vault - both role-ID and secret-ID. Does this thought process have a flaw somewhere?

Short summary:

  • I have an app that needs to get secrets from Vault.
  • It only calls Vault when the app user calls a specific API endpoint on the application.
  • A static service token is passed to the application from an environment variable to be used for all Vault authentication calls when the app starts.
  • That token is stored in one place and if it is leaked, that’s the only thing required to authenticate to Vault.
  • Trying to solve that issue by looking if this setup can be improved - token/credentials to be split between couple components (AppRole response wrapping with some other “proxy” for wrapping that I was initially talking about). Or any other solutions that are used in the industry.

Thanks for taking the time to respond!