Customized Hashicorp Vault Implementation

This is a customized implementation of the Hashicorp Vault image.

This augments the standard Hashicorp Vault image in 2 main ways:

1. It sets up the Hashicorp Vault in production mode but sets it up with an app authentication and unseals the vault so that the app can interact with it.
2. It adds a "snapshot server" which allows serving and receiving vault backups/snapshots over HTTP

Getting Started

First, you need to clone the repostiory:

git clone https://github.com/...

Next, you'll need to create a/the .env file (you can use the .env.example as a template)

cp .env.example .env

VAULT_NAME=pass-vault.identity.bridgemanaccessible.ca

Volumes

For the purposes of this piece there are two types of volumes:

• Host Mounted Volumes
• Shared Volumes

These are detailed bleow

Host Mounted Volumes

There are a number of volumes used that are intended to be mounted within the host system. This is so that these files can be viewed or backed up easily by administrators rather than having to dive into the containers file system itself.

These Host Mounted Volumes include:

• Configuration Directory
• Logs Directory
• Data Directory
• Backup/Creds Directory

Configuration Directory (/vault/config)

This is where configuration files for the vault go. In general, this doesn't require a lot of monitoring, maintenance or updating on a regular basis. It only needs to be updated when a change to the configuration of the vault is happening/desired.

Logs Directory (/vault/logs)

This is where log files used for tasks like debugging are intended to go. In general, the files in this directory are helpful but not thought of as critical.

Data Directory (/vault/data)

This is where all the actual data goes and therefore is a critical directory. This directory should be backed up and monitored as if something happens to it the vault won't function or restart properly.

Backup/Creds Directory (/vault/creds)

This is where "backup" files are kept. More specifically, things like a copy of the "root token" and "unseal keys" are kept here. This is because these values aren't as easily available after initialization but can become required. To that end, it's important to ensure this directory isn't shared too openly because these should be relatively confidential values.

Shared Volumes

Unlike the Host Mounted Volumes these volumes are intended to be shared across containers. That is, are more geared for program access rather than human access.

You can add these using Docker Compose:

services:
  app:
    volumes:
      - hashicorp-vault_role-vars:/role_vars

volumes:
  hashicorp-vault_role-vars:
    external: true

Replacing app and hashicorp-vault_role-vars with the appropriate values.

Note, the volume's "full name" will likely be the name of the directory followed by an underscore followed by the volumes name. Take the example above, the volume name is role-vars but the Docker compose is in and was run in the hashicorp-vault directory so the "full name" became hashicorp-vault_role-vars.

If your unsure you can check using docker volume list which lists all the volumes.

These Shared Volumes include:

• Role Vars

Role Vars (/role_vars)

This is where values that allow apps to use their appropriate "App Roles" are stored to be shared with the app.