I have difficulties using the Vault dev server mode in docker-compose environment. Other people have difficulties too.
Partly it’s due to incomplete/imperfect Vault documentation. I had to skim through the source code to understand what parameters can be used for some commands and for the dev server itself. Some of these were hard to find in the documentation.
I want Vault running in compose env with these features enabled on start:
- automatically unsealed
- enabled Vault Transit Engine
- two signing keys in Transit Engine, one ECDSA and one ED25519 with names
- predefined root token which can be embedded in all services needing to communicate with it
Here is a solution that works well.
Just use this. If you want to read some details follow below.
The dev server is always unsealed by default, so our first objective is achieved.
-dev-listen-address allows to bind to all interfaces, otherwise the Dev Server
automatically binds to
127.0.0.1. This prevents it from being visible from other
containers in the docker-compose network. It also prevents the Vault UI from
being accessible from the host machine at http://localhost:8200/ui/vault
-dev-root-token-id sets a predefined root token
for the dev server. The token can be set as a configuration variable in all
services which need to communicate with the Vault. (two objectives achieved)
The other two objectives - enable Transit Engine and create two keys inside it -
are achieved by the
vault-init.sh script which is started once as a separate
container. It connects to the running Vault container at http://vault:8200,
enables the Transit Engine and creates two keys.
Most parameters of the command to create keys are also undocumented. For example, to create a key of specific type, we can pass in a key=value pair. Looking at the source code you can see how parameters are read from stdin. To learn what parameters could be used in this (and other commands) I was observing the HTTP requests passed from the Vault UI in the browser to the Vault backend. For example, to create a a key with specific type you can use:
type parameter is undocumented, but there are many others that can be passed
as well, but you’ll have to look through the source code to see what can be used
for your specific use case.