Set up and configure Vault

14min

To set up and configure Vault, perform the following steps:
Download and install Vault.
Configure Vault.
Configure TCP listeners in the Vault configuration file.
Start the dev server.
Verify the server is running.
Access the Vault UI and modify the default ACL policy.
(Optional) Restart the dev server if it times out.
The following sections show you how to perform these tasks.
This integration guide assumes you are running the Vault server in Dev mode. When deploying Vault in a production setting, you must consider other things, such as the storage backend, but most concepts apply to dev and production. For specifics on how to deploy Vault in a production environment, refer to the HashiCorp Vault documentation: https://learn.hashicorp.com/tutorials/vault/getting-started-deploy.
For more information about how the dev server works, refer to https://www.vaultproject.io/docs/concepts/dev-server. 
Download and install Vault
Refer to the HashiCorp Vault documentation at the following link for instructions on how to download and install the Vault application: https://www.vaultproject.io/docs/install 
The second installation option at the preceding link uses a precompiled binary. Download these binaries at the following url: https://www.vaultproject.io/downloads 
To verify Vault works, run the following command on your system. You should see the help output. If you execute it from the command line, make sure the vault command is on your PATH or you might get an error about Vault not being found.
Shell
vault -h
vault -h
﻿
 Configure Vault
Vault uses documented sane defaults, so you need to set only non-default values in the configuration file.
1
Run the following command to create the /etc/vault.d directory:
Shell
sudo mkdir --parents /etc/vault.d
sudo mkdir --parents /etc/vault.d
﻿
2
Run the following command to create a Vault configuration file, vault.hcl:
Shell
sudo touch /etc/vault.d/vault.hcl
sudo touch /etc/vault.d/vault.hcl
﻿
3
Run the following command to create a unique, non-privileged system user to run Vault:
Shell
sudo useradd --system --home /etc/vault.d --shell /bin/false vault
sudo useradd --system --home /etc/vault.d --shell /bin/false vault
﻿
4
Run the following command to set the ownership of the /etc/vault.d directory:
Shell
sudo chown --recursive vault:vault /etc/vault.d
sudo chown --recursive vault:vault /etc/vault.d
﻿
5
Run the following command to set the file permissions:
Shell
sudo chmod 640 /etc/vault.d/vault.hcl
sudo chmod 640 /etc/vault.d/vault.hcl
﻿
Configure TCP listeners in the Vault configuration file
To configure the TCP listener addresses, you must edit the listener stanza, or selection of lines, in the vault.hcl fle on your server.
The TCP listener configures Vault to listen on a TCP address and port, as shown in the following example:
Text
listener "tcp" {
  address = "127.0.0.1:8200"
}
listener "tcp" {
  address = "127.0.0.1:8200"
}
﻿
You can specify the listener stanza more than once to make Vault listen on multiple interfaces. If you configure multiple listeners, you also need to specify api_addr and cluster_addr so Vault advertises the correct address to other nodes. 
The following sample vault.hcl configuration file (used for demonstration in this guide) shows Vault listening on a private interface, as well as localhost.
You must customize the values defined in the vault.hcl file for each specific use case (such as IP addresses, ports, and file paths to certificates). 
Text
# Configure the storage backend for Vault
storage "file" {
  path = "/tmp/vault"
}

# Address and port on which Vault responds to requests from the KMES Series 3
listener "tcp" {
  address = "10.0.5.118:8210"
  tls_disable = false
  tls_cert_file = "/home/bbarrows/Documents/Vault/client-cert.pem"
  tls_key_file = "/home/bbarrows/Documents/Vault/client-privatekey.pem"
}

# Enable the Vault web UI
ui = true

# Lock process memory pages, preventing them from being swapped to disk
disable_mlock = true
# Configure the storage backend for Vault
storage "file" {
  path = "/tmp/vault"
}

# Address and port on which Vault responds to requests from the KMES Series 3
listener "tcp" {
  address = "10.0.5.118:8210"
  tls_disable = false
  tls_cert_file = "/home/bbarrows/Documents/Vault/client-cert.pem"
  tls_key_file = "/home/bbarrows/Documents/Vault/client-privatekey.pem"
}

# Enable the Vault web UI
ui = true

# Lock process memory pages, preventing them from being swapped to disk
disable_mlock = true
﻿
The comments above each block in the file explain what the define lines do.
Critically, note that 10.0.5.118 is the IP address of the machine that Vault is installed on, and 8210 is the port on which Vault listens for requests from the KMES Series 3. 
Also, make sure that the client certificate common name matches the IP address set in vault.hcl. Otherwise, the KMES Series 3 does not verify the certificates presented by Vault to the KMES Series 3. 
cluster_address is not defined in the sample vault.hcl file because this demo uses only a single Vault server.
For more information about configuring the Vault configuration file, see the Vault documentation at the following URL: https://learn.hashicorp.com/tutorials/vault/configure-vault 
Start the dev server
To start the Vault dev server, run the following command:
Shell
vault server -dev -config=/etc/vault.d/vault.hcl 
vault server -dev -config=/etc/vault.d/vault.hcl 
﻿
You should see output similar to the following example. Notice that Unseal Key and Root Token values display.
Shell
$ vault server -dev -config=/etc/vault.d/vault.hcl 
==> Vault server configuration:

             Api Address: https://10.0.5.118:8210
                     Cgo: disabled
         Cluster Address: https://10.0.5.118:8211
              Go Version: go1.14.7
              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")
              Listener 2: tcp (addr: "10.0.5.118:8210", cluster address: "10.0.5.118:8211", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
              Listener 3: tcp (addr: "127.0.0.1:8210", cluster address: "127.0.0.1:8211", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
           Recovery Mode: false
                 Storage: file
                 Version: Vault v1.5.4+ent
             Version Sha: 1d81c1e64854fb0dcb3323468d95ad5590460a40

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

You may need to set the following environment variable:

    $ export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: I29KTEqQVcl2Pa3xKgXffcwP9ae0ow157NFuG7Pj14A=
Root Token: s.XtzYp0lIJtaW3fMAtgWHdXxo

Development mode should NOT be used in production installations!

==> Vault server started! Log data will stream in below:
$ vault server -dev -config=/etc/vault.d/vault.hcl 
==> Vault server configuration:

             Api Address: https://10.0.5.118:8210
                     Cgo: disabled
         Cluster Address: https://10.0.5.118:8211
              Go Version: go1.14.7
              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")
              Listener 2: tcp (addr: "10.0.5.118:8210", cluster address: "10.0.5.118:8211", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
              Listener 3: tcp (addr: "127.0.0.1:8210", cluster address: "127.0.0.1:8211", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
           Recovery Mode: false
                 Storage: file
                 Version: Vault v1.5.4+ent
             Version Sha: 1d81c1e64854fb0dcb3323468d95ad5590460a40

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

You may need to set the following environment variable:

    $ export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: I29KTEqQVcl2Pa3xKgXffcwP9ae0ow157NFuG7Pj14A=
Root Token: s.XtzYp0lIJtaW3fMAtgWHdXxo

Development mode should NOT be used in production installations!

==> Vault server started! Log data will stream in below:
﻿
The dev server stores all its data encrypted in memory, listens on localhost without TLS, and automatically unseals and shows you the unseal key and root access key.
With the dev server started, perform the following steps:
1
Launch a new terminal session.
2
Set the VAULT_ADDR environment variable value by running the following command in the terminal. This configures the Vault client to talk to the dev server.
Shell
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_ADDR='http://127.0.0.1:8200'
﻿
Vault CLI uses the VAULT_ADDR environment variable to determine to which Vault servers to send requests.
3
Save the unseal key somewhere. You don't need to save this securely.
4
Set the VAULT_TOKEN environment variable value to the generated Root Token value displayed in the terminal output when you started the dev server. 
Shell
export VAULT_TOKEN="s.akT1I498dqOy4Z2C5ZimASlR"
export VAULT_TOKEN="s.akT1I498dqOy4Z2C5ZimASlR"
﻿
To interact with Vault, you must provide a valid token. Setting this environment variable provides the token to Vault through the CLI.
Verify the server is running
Verify the server is running by executing the vault status command. If it started properly, the output should look similar to the following example:
Shell
$ vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.5.4+ent
Cluster Name    vault-cluster-8667d21d
Cluster ID      b3977a72-9be9-d900-c0ec-c6012b1902da
HA Enabled      false
$ vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.5.4+ent
Cluster Name    vault-cluster-8667d21d
Cluster ID      b3977a72-9be9-d900-c0ec-c6012b1902da
HA Enabled      false
﻿
In the Enterprise version of Vault, the dev server seals itself 30 minutes after you start it. This means that for the Enterprise version of Vault, you must perform the steps in the Restart the dev server if it times out section every time the dev server times out.
For more information about how the dev server works, refer to https://www.vaultproject.io/docs/concepts/dev-server.
Access the Vault UI
1
Go to http://localhost:8200 in a web browser. 
2
Copy and paste the Root Token in the Token field and select [ Sign In ]. The Root Token displays in the output of the vault server command you used to start the dev server.
Modify the default ACL policy
After signing in, perform the following steps to modify the default ACL policy:
1
Go to the Policies menu, then select the default ACL policy.
2
Select [ Edit Policy ], scroll to the bottom of the policy, and paste the following lines starting at line 89 of the policy:
Text
path "secret/data/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "secret/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "sys/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}
path "sys/mounts/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}
# List enabled secrets engine
path "sys/mounts" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}
# Work with pki secrets engine
path "pki*" {
  capabilities = [ "create", "read", "update", "delete", "list", "sudo" ]
}
path "secret/data/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "secret/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "sys/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}
path "sys/mounts/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}
# List enabled secrets engine
path "sys/mounts" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}
# Work with pki secrets engine
path "pki*" {
  capabilities = [ "create", "read", "update", "delete", "list", "sudo" ]
}
﻿
3
Select [ Save ].
A message confirms that the ACL policy default was successfully saved.
Restart the dev server if it times out
In the Enterprise version of Vault, the dev server seals itself 30 minutes after you start it. This means that for the Enterprise version of Vault, you must perform the following steps every time the dev server times out:
1
Trigger a Vault shutdown by using CTRL+C in the terminal window where you started the Vault server. 
2
Run the following command in a terminal:
Shell
rm -r /tmp/vault/
rm -r /tmp/vault/
﻿
3
Perform again the steps outlined in the following sections:
Configure Vault
Start the dev server
Access the Vault UI
Modify the default ACL policy
4
Re-configure either the userpass or TLS authentication auth method in Vault, as described in section Set up authentication between the KMES Series 3 and Vault.
﻿

Updated 27 Feb 2024

Did this page help you?

Configure TLS certificates for mutual authentication between HashiCorp Vault and the KMES Series 3

Set up authentication between the KMES Series 3 and Vault