Deployment

Deploying an application that uses Valt0 works much like developing one: the application still asks a Valt0 service beside it for its secrets.

What changes is how a vault is opened. On a server or in a container there is nobody to type a vault key, so a deployment opens it with two keys made for the purpose, one used when the application is built and one when it starts.

Install Valt0 beside your app

Valt0 has to be installed on the server or in the container your application is deployed to.

A client connects to the Valt0 service on the same machine as your application. That is by design: Valt0 takes very few resources to run, and being close to your application is a real gain for security.

So if your application runs in a container, Valt0 has to be installed in that container, with a line like this in your Dockerfile. --version pins the release that is installed:

Dockerfile

RUN wget -qO- https://dl.valt0.com/v1/latest/install.sh | sh -s -- --version 0.0.50-pre

If you use the same container for development and for deployment, that is fine: the Valt0 installed in the container does not conflict with the one installed on your machine.

Ship your vaults

The vaults your application uses have to be on the server or in the container as well.

A vault is one file, so this is the same as shipping any other file with your application. In a container it has to be in the image before the build primes it, which is the next step.

Make the deployment keys

Opening a vault in a deployment takes two steps, prime and unlock, and each step needs a key of its own.

Everything a deployment needs is under valt0 deploy. Run valt0 deploy generate-keys once, on your own machine, to make the two keys for a vault. The prime key is printed as text; the unlock key is always a file.

The vault key and the deployment keys do different jobs. The vault key is for working with a vault on your own machine: adding, changing and removing secrets. The prime key and the unlock key are for deploying it.

$valt0 deploy generate-keys secrets.valt0

Prime at build time

The first step, valt0 deploy prime, runs when your application is built. It takes the vault’s path and the prime key.

If you deploy in containers, that is a line in your Dockerfile:

Dockerfile

RUN valt0 deploy prime secrets.valt0 VLT0-PRIME-KEY-...

It is fine for the prime key to be in your build scripts or your Dockerfile. On its own it cannot unlock the vault: that also takes the unlock key file.

Unlock at run time

The second step happens when your deployed application starts: Valt0 unlocks each primed vault with its unlock key file.

Put the unlock key files for every vault you want unlocked in one directory, and make sure Valt0 can read it. In a container that is usually a mounted volume, or any other way of giving the container a directory when it starts.

Then set two environment variables. VALT0_UNLOCK_KEYS_DIR is the path to that directory, which is where Valt0 picks up the unlock keys to unlock the primed vaults. VALT0_MODE is set to deploy, which tells Valt0 it is running in deployment mode.

Deploy to a server

On a server the steps are the same, with one difference: prime your vaults with --preserve.

Prime each vault with its prime key, and keep the unlock keys in a directory, as above.

By default, once a vault is unlocked, Valt0 tries to delete the prime key and the primed vault from disk and keep them only in memory, which makes them harder to take. That suits a container, which is thrown away and recreated, priming and unlocking afresh each time. A server is restarted instead, and after a restart the unlock finds no prime key and no primed vault, and fails. --preserve keeps them on disk.

$valt0 deploy prime secrets.valt0 VLT0-PRIME-KEY-... --preserve