Setting Up A Local HashiCorp Vault Server

Basic Setup

Download the binary: https://www.vaultproject.io/downloads/

Launch the server in dev mode (no database needed, in-memory persistence):

./vault server -dev

The program output displays important credentials to authenticate with the server. The vault client has already been logged in so there is no need to use these. But if testing the go client or making API calls, these will be required:

Unseal Key: +55s6SW/FZ+YTKhH3dBGsH2lqx4iUvs3OukWudK6PpY=
Root Token: s.44H7AnfV36MOuuskEBJnHEAQ

Will use the same vault binary as the client program to interact with the server.

Point the client to the server with the credentials token:

export VAULT_ADDR='http://127.0.0.1:8200'
export TOKEN=s.44H7AnfV36MOuuskEBJnHEAQ

Deploy A Non-Dev Vault

Use the following minimalistic configuration for a non-dev vault server, and save as config.hcl:

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

"api_addr"="http://127.0.0.1:8200"
"plugin_directory" = "/Users/<username>/.vault.d/vault_plugins"

Start the server:

$ vault server -config=config.hcl

A non-dev server must be initialized to generate the unsealing keys and the root token:

$  ./vault operator init
Unseal Key 1: eaFFzG8GlnALXCC4ed3zElVEwD069A9HGdubRVfLF7q4
Unseal Key 2: bBihgEsi8K7jclduplkpQYuWHXVcywFZUqDyjUQG0HXP
Unseal Key 3: 4xynONQujxHptUa8L8Vj7O0iBgCwKkrMRxVtgT4apUhi
Unseal Key 4: gcMs+4MVksj939NDjCK4aoizaCPB9fz35YdlbgRFR+SH
Unseal Key 5: nsdsAnBjqLTfHuKsxJh8Q9hhWlh+caxPH3I9bqKz9h+8

Initial Root Token: s.LDxyeohQ8BfKDMdTAMgsMmw4

Unseal the server using 3 out of the 5 key shards (because by default the threshold is 3):

$ ./vault operator unseal

Next is to Log in the vault client with the root token:

./vault login

This command must be run 3 times each time inputting a different key chards from the list displayed above.

The non-dev mode does not define a kv secret engine like the dev mode does. So after the server is successfully unsealed, enable a kv secret engine and mount to the path secret

$ ./vault secrets enable -path=secret kv
Success! Enabled the kv secrets engine at: secret/

Note that unlike the dev mode, accessing the path created this way does not require the extra /data segment. So for both API calls and policies, use the path /secret/<secret_name> without the /data.

Enabling The Ethereum HSM Plugin

After building from the repository source, copy the binary ethsign to the plugins folder specified by the configuration file:

$ cp ethsign /Users/<username>/.vault.d/vault_plugins

Generate a SHA256 hash for the server to verify the binary's authenticity:

$ export SHASUM256=$(shasum -a 256 "ethsign" | cut -d' ' -f1)

Register the plugin with the vault server:

$ ./vault write sys/plugins/catalog/ethsign sha_256="${SHASUM256}" command="ethsign"
Success! Data written to: sys/plugins/catalog/ethsign

Activate the plugin as a secret engine on the /ethereum path:

$ ./vault secrets enable -path=ethereum -description="Ethereum HSM Signing Wallet" -plugin-name=ethsign plugin
Success! Enabled the ethsign secrets engine at: ethereum/

Create Non-Root Access Tokens

Typical usage of the vault should NOT be done with the root token, which gives the client complete administrative access. More likely customers would configure tokens that are tied to specific access policies.

Define a policy with a file apps-policy.hcl:

# Read-only permit
path "secret/data/kaleidoSigningKey" {
  capabilities = [ "read" ]
}

Create the policy on the server:

$ vault policy write apps apps-policy.hcl

Then create a token with the access privilege as specified in the policy:

$ vault token create -policy="apps"
Key                  Value
---                  -----
token                s.GJ6iGVxAF1W0IXYSCOfxAri6
token_accessor       bjirbvWvDBNcUBJBIFkuoT3M
token_duration       768h
token_renewable      true
token_policies       ["apps" "default"]
identity_policies    []
policies             ["apps" "default"]