freeZion

I recently wanted to get a working vault instance running. Since my goal is to sharpen my devops skillset, I had some specific features I wanted to make sure I had nailed down:

• Run vault in server mode, rather than dev
• Run it in Docker, ideally using docker-compose
• Have other containers access the vault for secrets
• Use a persistent storage mechanism for the backend
  • I didn’t want to use files for this

To meet the storage requirements, after looking into it a little bit it became apparent that Consul was probably the right move (as of this post, it’s the only database engine that’s officially supported by Hashicorp for Vault — which makes sense since they make both products).

It turns out that getting Vault and Consul up and running – and talking to each other – is not as straightforward as it could be. I found lots of examples, but most of them did not work anymore, and all of them used version 2 of the docker-compose spec. After much trial and error and a ton of failure, I finally got things running successfully. If you want to try it out, you can check it out at https://github.com/rossja/docker-vault-consul/

One thing to note: as configured in the repo the Vault container talks to Consul over HTTP. Since the secret is encrypted inside vault, no sensitive data is being passed in plaintext over the network (in theory), but it’s still not the best-practice to use HTTP here.

The problem is that there’s a bit of a chicken/egg problem with using HTTPS… specifically: you need to securely get certificates and privatekeys into the Vault and Consul containers in order for TLS to work properly. But doing that means either:

1) checking the certs into a repo, or
2) passing them into the container via something like a volume or ENV var.

Neither of these are ideal.

I’ll probably ultimately end up opting for passing them in via a bootstrap volume of some kind, but am still thinking over how best to handle this.