Secrets Storage With Vault On Your Home Server

7 minute read

You may be looking for a self-hosted solution for storing passwords and other secrets that you may not feel comfortable having in the cloud. Vault by HashiCorp is an enterprise secrets storage solution with both web based and command line access. It’s open source and you can run it for free at home.

I do not recommend exposing this to the clearnet. My Vault server requires I hop onto my home network’s VPN. I don’t doubt Vault’s security, but leaving it out in the open is opening you up to the same worries that come with using a commercial password manager or your browser’s built in sync functionality. The goal here is to stash all this away.

For this guide, I’m using Debian, but I’ll try to keep this as distro agnostic as possible.

Download and Install

Let’s start by creating a system user account for Vault.

# useradd -r vault

Go to https://www.vaultproject.io/downloads and find the link to your architecture, then download and extract the vault binary to /usr/local/bin. Example as of the time of writing:

# wget https://releases.hashicorp.com/vault/1.6.3/vault_1.6.3_linux_amd64.zip
# unzip vault_1.6.3_linux_amd64.zip
# mv vault /usr/local/bin
# mkdir /etc/vault
# chown vault:vault /etc/vault

### Configure a Storage Backend

There are many options for this. Consult the documentation and follow the instructions for your preferred method. Chances are if you’re running a homeserver, you already have Postgres, MySQL or MariaDB running for other apps. We can keep life simple and just use that. For my example, I’m using Postgres on Debian.

# apt install postgresql-all
# su -c psql postgres

In the Postgres shell, we’ll create a user, password, and database for Vault.

postgres=# CREATE DATABASE vault;
CREATE DATABASE
postgres=# CREATE ROLE vault WITH LOGIN PASSWORD '3Mq685AS2Zjzt2zZ2hTQ0zI4ZjmHoJoP';
CREATE ROLE
postgres=# GRANT ALL ON DATABASE vault TO vault;
GRANT
postgres=# EXIT

Now login as the vault user.

# psql -U vault -d vault -h localhost
Password for user vault: 
psql (13.2 (Debian 13.2-1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

vault=>

This SQL code will create the necessary schema. Note that this is copied verbatim from HashiCorp’s documentation.

CREATE TABLE vault_kv_store (
  parent_path TEXT COLLATE "C" NOT NULL,
  path TEXT COLLATE "C",
  key TEXT COLLATE "C",
  value BYTEA,
  CONSTRAINT pkey PRIMARY KEY (path, key)
);

CREATE INDEX parent_path_idx ON vault_kv_store (parent_path);

Configure the Service

Okay, now we want to create a config file for Vault.

# touch /etc/vault/config.hcl
# chown vault:vault /etc/vault/config.hcl
# chmod 600 /etc/vault/config.hcl

Edit and add the following.

storage "postgresql" {
  connection_url = "postgres://vault:3Mq685AS2Zjzt2zZ2hTQ0zI4ZjmHoJoP@localhost:5432/vault?sslmode=disable"
}

listener "tcp" {
  address = "127.0.0.1:8200"
  tls_disable = 1
}

api_addr = "http://127.0.0.1:8200"
ui = true
disable_mlock = true

A few things to note here, the listener address being set to local means we’ll need a reverse proxy to this to be able to access it from the outside. Setting ui to true means we’ll have a web portal we can access it from. We’ll be limiting access to that later. disable_mlock is required in order to run Vault as a non-root user. If you have unencrypted swap space, this is insecure and you’ll need to run Vault as root.

Create the necessary systemd config in /etc/systemd/system/vault.service

[Unit]
Description=Vault
After=network.target postgresql.service
Requires=network.target

[Service]
User=vault
Group=vault
ExecStart=/usr/local/bin/vault server -config=/etc/vault/config.hcl
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=vault

Create directory /var/log/vault and set Vault as the owner. Create /etc/rsyslog.d/vault.conf and add the following:

if $programname == 'vault' then /var/log/vault/vault.log
& stop

And finally, create /etc/logrotate.d/vault.conf to complete our service setup.

/var/log/vault/vault.log {
    rotate 4
    weekly
    missingok
}

Now get everything started.

# systemctl restart rsyslog
# systemctl start vault

Initial Setup

Now we need to initialize Vault. You can do the following as an unprivileged user, but first let’s unset the history file so sensitive data isn’t stored there.

blake@vault-test:~$ unset HISTFILE
blake@vault-test:~$ export VAULT_ADDR="http://127.0.0.1:8200"
blake@vault-test:~$ vault operator init
Unseal Key 1: HemGy27C/An1PD/Rvmh+Scwv/h4rofatbBbEece/RKBG
Unseal Key 2: 0lZeThunWO1C/7hjrztIP6ayLfnLzeANZvgtRwM/u4Gs
Unseal Key 3: RqL+cLBcyLrBp2uC0+rOMb7umFEE4baHmta6VjdBVAIF
Unseal Key 4: tsadSAQzM7Lz6Ru5o7SyXeFwr1OblNca0G4NB5a1PqjT
Unseal Key 5: Ynss3Uocie6RJnVSkuIN+mB1FOzx0VOEKC45jhMUWoKB

Initial Root Token: s.aIajFemqnJ3f06vzGIjMi75P

Vault initialized with 5 key shares and a key threshold of 3. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 3 of these keys to unseal it
before it can start servicing requests.

Vault does not store the generated master key. Without at least 3 key to
reconstruct the master key, Vault will remain permanently sealed!

It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.

Your paranoia level will determine where you store your keys. You could keep them on separate encrypted devices if you wish. Also, be careful with the root token as it never expires.

Alright! Now to unseal, run vault operator unseal [key] with 3 different keys, one at a time. You can now login with the initial root token.

blake@vault-test:~$ vault login s.aIajFemqnJ3f06vzGIjMi75P
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key Value
--- -----
token s.aIajFemqnJ3f06vzGIjMi75P
token_accessor oz6lMguYyxuBmfdcDFOxEo3n
token_duration ∞
token_renewable false
token_policies ["root"]
identity_policies []
policies ["root"]

So we’re going to want to create a store for our passwords and then create a limited user with access to it.

blake@vault-test:~$ vault secrets enable -path=passwords kv-v2
Success! Enabled the kv-v2 secrets engine at: passwords/

To create a policy with access to this resource, create and edit a file called password-policy.hcl

path "passwords/*"
{
  capabilities = ["create", "read", "update", "delete", "list"]
}

Now let’s create a user with access to this keystore.

blake@vault-test:~$ vault policy write password-policy password-policy.hcl 
Success! Uploaded policy: password-policy
blake@vault-test:~$ vault auth enable userpass
blake@vault-test:~$ vault write auth/userpass/users/blake password=ThisIsATestPassword policies=password-policy
Success! Data written to: auth/userpass/users/blake

Managing Secrets with the CLI

Let’s login as our new user and make sure we’re able to store a secret.

blake@vault-test:~$ vault login -method=userpass username=blake
Password (will be hidden): 
Success! You are now authenticated.
blake@vault-test:~$ vault kv put passwords/yahoo login="[email protected]" password="somepassword"
Key Value
--- -----
created_time 2021-02-28T13:55:32.900321369Z
deletion_time n/a
destroyed false
version 1
blake@vault-test:~$ vault kv get passwords/yahoo
====== Metadata ======
Key Value
--- -----
created_time 2021-02-28T13:55:32.900321369Z
deletion_time n/a
destroyed false
version 1

====== Data ======
Key Value
--- -----
login [email protected]
password somepassword

Using put again will overwrite all key entries. Use patch to add a value without deleting.

blake@vault-test:~$ vault kv patch passwords/yahoo "mother's maiden name"=99l4Jhp7
Key Value
--- -----
created_time 2021-02-28T15:08:20.132487093Z
deletion_time n/a
destroyed false
version 2
blake@vault-test:~$ vault kv get passwords/yahoo
====== Metadata ======
Key Value
--- -----
created_time 2021-02-28T15:08:20.132487093Z
deletion_time n/a
destroyed false
version 2

============ Data ============
Key Value
--- -----
login [email protected]
mother's maiden name 99l4Jhp7
password somepassword

Alright, so we’re able to store and view passwords using the command line. This is practical if you have an ssh jump into your home network. The web interface is definitely much easier to work with though if you’re running a VPN instead. So let’s get that setup.

Configuring a Reverse Proxy

For the sake of this tutorial, I’m going to recommend Nginx as a reverse proxy. Much like with the database, your home server is probably already running this or Apache. I’ll be using a LetsEncrypt certificate for good measure, but if your webserver isn’t remote accessible at all, you might wind up using a self-signed cert instead.

# apt install nginx certbot python3-certbot-nginx
# certbot certonly --nginx -d vault.yourdomain.ext

Add an entry for Vault in /etc/nginx/sites-available/vault.conf

server {
  listen 80;
  server_name vault.yourdomain.ext;
  return 301 https://vault.yourdomain.ext$request_uri;
  access_log /var/log/nginx/vault.access.log;
  error_log /var/log/nginx/vault.error.log;
}

   
server {
  listen 443 ssl;     
  server_name vault.yourdomain.ext;

  access_log /var/log/nginx/vault.access.log;
  error_log /var/log/nginx/vault.error.log;

  ssl_session_cache shared:SSL:1m;
  ssl_session_timeout 10m;
  ssl_ciphers HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers on;
  ssl_certificate /etc/letsencrypt/live/vault.yourdomain.ext/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/vault.yourdomain.ext/privkey.pem;

  location / { 
    proxy_pass http://127.0.0.1:8200/;
    proxy_buffering off;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    client_max_body_size 0;
    # Only allow the internal network
    allow 192.168.122.0/24;
    allow 127.0.0.1/32;
    deny all;
  }
}

With this configuration, Vault will always use https and send a 403 to requests from the public internet.

# ln -s /etc/nginx/sites-available/vault.conf /etc/nginx/sites-enabled/vault.conf
# nginx -t
# systemctl restart nginx

Managing Secrets with the Web UI

So now you should be able to login through the web portal. Change the login method to Username and we’ll sign in with our limited user.

We can see the passwords keystore we created before.

From here, we can either look at the secret we stored manually before, or create a new one. Let’s add another password.

That’s it! You now have a working Vault service serving an actual purpose on your home server. From here, you may as well spin up some new kv stores and users and start developing apps that use it.

Share on

Twitter Facebook LinkedIn

Blake Carpenter