# AppRole secrets retrieval pattern

**URL:** <https://discuss.hashicorp.com/t/approle-secrets-retrieval-pattern/34239>\
**Category:** Vault\
**Created:** [January 13, 2022, 6:58pm UTC](https://discuss.hashicorp.com/t/approle-secrets-retrieval-pattern/34239 "2022-01-13T18:58:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Wufe](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/wufe/32/25100_2.png) [@Wufe](https://discuss.hashicorp.com/u/Wufe)\
**Post date:** [January 13, 2022, 6:58pm UTC](https://discuss.hashicorp.com/t/approle-secrets-retrieval-pattern/34239/1 "2022-01-13T18:58:00Z")

</div>

Hi,  
I was thinking about using Vault for my experimental backend architecture (side project) and I’ve stumbled upon a dilemma.

I’m currently developing this architecture with scalability in mind but starting from simple docker container with no particular orchestration: I’m just using docker-compose.

In order to authenticate the services hosted in my containers, I’m using the app-role authentication pattern.

My dilemma is this:  
since I haven’t build a complex CI pipeline or similar (just using docker-compose), how can I distribute the AppRole’s role **secret-id** ’s to my applications?  
The role-id can be hardcoded, maybe during `docker build`, but the secret cannot be hardcoded, also because from what I understood, the secrets and the tokens are short-lived and it’s a bad practice to make them with a high TTL.

Reading the tutorial page titled “Recommended Pattern for Vault AppRole Use”, it says that a CI worker should have a token capable of requesting secret-id’s given an app’s role-id.  
But since I have no CI and no CI worker how can I accomplish that?

I was thinking about making a custom “secret manager” service configured with a long-lived _non-root_ token, capable (with a policy) of only retrieving secret-id’s for the other services.  
This service would be storing a public key for each service that’s gonna communicate with it.  
A client service -for example an application worker- then communicates with this “secret manager” and asks for a secret-id given a role-id, signing the request with its private key.  
The “secret manager” service could then respond to the request generating a secret-id and wrapping it.

It would basically be a service for asking the secret-id for any role-id, given the client service is authenticated to this “secret manager” service.

Could this be a feasible implementation, or is it viewed as an anti-pattern?

I’d try to strengthen the security of this communication using asymmetric encryption within parties with pre-shared public keys and wrapped tokens.

---

<div class="post-metadata">

**Author:** ![rgevaert](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/rgevaert/32/8908_2.png) [@rgevaert](https://discuss.hashicorp.com/u/rgevaert)\
**Post date:** [February 2, 2022, 9:28pm UTC](https://discuss.hashicorp.com/t/approle-secrets-retrieval-pattern/34239/2 "2022-02-02T21:28:11Z")

</div>

Q: how would you distribute the private key you are talking about?

Do you see this threat [Secrets for docker-compose services - #4 by Wolfsrudel](https://discuss.hashicorp.com/t/secrets-for-docker-compose-services/6265/4) ?