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.