A Vault Tutorial. Part 5

by Isaac Johnson

So far our basic containerized Vault has worked for dev, but it’s not re-deployable in its current fashion.  We would never use in-memory storage for keys (wanting instead to persist them).

We can use HCL to define a storage backend and launch Vault locally to verify the HCL.

To illustrate, I created a sample Azure storage account, blob container and provided a key.

$ cat idj-azure-vault.hcl 
storage "azure" {
  accountName = "idjvaulttest"
  accountKey  = "d51Zm0CSnNamDvTrUL7AAxu+yWIc4+MrdDD1WulbWg85CoJYFWDA2euajy+57jiF3jz87CqxfoLWzAnzL5fUcw=="
  container   = "idjvaultcontainer"
}

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

$ vault server -config=idj-azure-vault.hcl 
WARNING! mlock is not supported on this system! An mlockall(2)-like syscall to
prevent memory from being swapped to disk is not supported on this system. For
better security, only run Vault on systems where this call is supported. If
you are running Vault in a Docker container, provide the IPC_LOCK cap to the
container.
==> Vault server configuration:

                     Cgo: disabled
              Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
               Log Level: (not set)
                   Mlock: supported: false, enabled: false
                 Storage: azure
                 Version: Vault v1.0.1
             Version Sha: 08df121c8b9adcc2b8fd55fc8506c3f9714c7e61

==> Vault server started! Log data will stream in below:

2019-01-01T12:58:21.205-0600 [WARN]  no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value should be manually set

Operator Init

The first time we launch Vault against a new backend we need to “init” the cluster.

Here you can see i changed from the default port (9990) and init’ed the local instance (running against Azure Blob storage);

$ cat idj-azure-vault.hcl 
storage "azure" {
  accountName = "idjvaulttest"
  accountKey  = "d51Zm0CSnNamDvTrUL7AAxu+yWIc4+MrdDD1WulbWg85CoJYFWDA2euajy+57jiF3jz87CqxfoLWzAnzL5fUcw=="
  container   = "idjvaultcontainer"
}

listener "tcp" {
 address     = "127.0.0.1:9990"
 tls_disable = 1
}
$ vault server -config=idj-azure-vault.hcl
WARNING! mlock is not supported on this system! An mlockall(2)-like syscall to
prevent memory from being swapped to disk is not supported on this system. For
better security, only run Vault on systems where this call is supported. If
you are running Vault in a Docker container, provide the IPC_LOCK cap to the
container.
==> Vault server configuration:

                     Cgo: disabled
              Listener 1: tcp (addr: "127.0.0.1:9990", cluster address: "127.0.0.1:9991", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
               Log Level: (not set)
                   Mlock: supported: false, enabled: false
                 Storage: azure
                 Version: Vault v1.0.1
             Version Sha: 08df121c8b9adcc2b8fd55fc8506c3f9714c7e61

==> Vault server started! Log data will stream in below:
..2019-01-01T13:12:08.434-0600 [INFO]  core: cluster listeners successfully shut down
2019-01-01T13:12:08.434-0600 [INFO]  rollback: stopping rollback manager
2019-01-01T13:12:08.434-0600 [INFO]  core: pre-seal teardown complete

Now we can connect with operator init to get our unseal keys.  By default Vault is configured to split keys into 5 shares requiring a minimum of 3.  

$ export VAULT_ADDR="http://127.0.0.1:9990"
AHD-MBP13-048:~ isaac.johnson$ vault operator init
Unseal Key 1: 7Zk7e298NV1ZRT9rouryXf1O41/erScyoaUOANibj/p0
Unseal Key 2: aqephGg4K6DFp4gFrK+XuR+g1RCOOcuurxLL42AiXXFK
Unseal Key 3: nKkeSIDVChwZDiFrYv+WmHiTT7ujM+rL3+uzGWkT3ZRU
Unseal Key 4: NiNOyWEGqaR2ssveIFDMA7bWrLoYBzSnDHKUOzjT2RyW
Unseal Key 5: uX8zJXydLHFKntbqEcSSpYVHzkMKYhVxfN/w6c60wl29

Initial Root Token: s.GajsySoAWg7fWANaA1jYB1ws

Vault initialized with 5 key shares and a key threshold of 3. Please securely...

Unsealing

Everytime a Vault server starts, it does so in a sealed state.  We need to unseal it with at least 3 of these keys.  

We can use the operator unseal commands to unseal the Vault.  When we’ve reached the threshold, we can see “Sealed” changes to false

$ vault operator unseal
Unseal Key (will be hidden): 
Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    1/3
Unseal Nonce       160f8b32-c70e-80a5-aa85-abbd09ae9a3b
Version            1.0.1
HA Enabled         false
$ vault operator unseal
Unseal Key (will be hidden): 
Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    2/3
Unseal Nonce       160f8b32-c70e-80a5-aa85-abbd09ae9a3b
Version            1.0.1
HA Enabled         false
$ vault operator unseal
Unseal Key (will be hidden): 
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    5
Threshold       3
Version         1.0.1
Cluster Name    vault-cluster-f2fb0f8a
Cluster ID      2b8cfa34-80ef-5b56-90cf-c1b9060215f5
HA Enabled      false

$ vault login s.GajsySoAWg7fWANaA1jYB1ws
Success! You are now authenticated. The token information displayed below… 

…
==> Vault server started! Log data will stream in below:

2019-01-01T13:17:09.189-0600 [WARN]  no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value should be manually set
2019-01-01T13:19:01.121-0600 [INFO]  core: vault is unsealed
2019-01-01T13:19:01.326-0600 [INFO]  core: post-unseal setup starting
2019-01-01T13:19:01.436-0600 [INFO]  core: loaded wrapping token key
...