Vault with Consul Storage Deployment Guide
This guide applies to Vault versions 1.7 and above and Consul versions 1.8 and above.
This deployment guide outlines the required steps to install and configure a single HashiCorp Vault cluster as defined in the Vault with Consul Storage Reference Architecture on virtual machines (VMs) or bare-metal servers running a Debian- or RedHat-based Linux distribution.
This guide includes general guidance as well as specific recommendations for popular cloud infrastructure platforms.
For production
Integrated Storage native to Vault is now recommended rather than using Consul for Vault storage. Refer to the Vault with Integrated Storage Deployment Guide to deploy Vault with Integrated Storage.
Vault Enterprise
As of version 1.12.0, Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. See the Release Notes.
Prerequisites
You must have already set up a Consul cluster to use for Vault storage according to the Consul Deployment Guide including ACL bootstrapping.
It is strongly recommended to deploy a dedicated Consul cluster for this purpose, as described in the Vault with Consul Storage Reference Architecture to minimize resource contentation on the storage layer.
The remaining steps should be followed on each Vault server in your cluster.
Install Vault and Consul
Pre-built Vault and Consul packages are available from the HashiCorp Linux
Repository.
In addition to the installing the appropriate binaries, the official packages
seed Vault and Consul with a baseline configuration, a systemd service unit, and
local vault
and consul
user accounts under which the corresponding services
will be run.
Add the HashiCorp GPG key as a trusted package-signing key.
Add the official HashiCorp Linux repository.
Update the package index.
Install Vault and Consul.
Note
To install open source Vault or Consul, replace vault-enterprise
with vault
and consul-enterprise
with consul
.
Prepare TLS certificates
Note
The installation package generates a self-signed TLS certificate for use by the Vault service to secure intra-cluster communication. While these certificates are usable for experimenting with getting Vault up and running, HashiCorp strongly recommends replacing them with certificates generated and signed by an appropriate CA.
You must have three files to configure TLS for Vault. Place them at these paths:
/opt/vault/tls/vault-cert.pem
- The Vault TLS certificate itself. If this file was signed by an intermediate CA, append the certificate of that CA (and any other chained CAs) to the end of this file./opt/vault/tls/vault-key.pem
- The private key of the Vault TLS certificate./opt/vault/tls/vault-ca.pem
- The certificate of the CA root which signed the Vault TLS certificate.
Set the file ownership of the CA and certificate files to be owned by root.
Set the file group ownership of the private key to allow the Vault service to read the file.
Set the file permissions of the CA and certificate files to be world-readable.
Set the file permissions of the private key file to be readable only by the Vault service.
Configure the Consul agent
Consul may be configured by editing the /etc/consul.d/consul.hcl
file included
with the installation package, or by creating additional .hcl
files in the
/etc/consul.d
directory. A typical configuration file is given below, but the
exact settings may vary significantly. Refer to the Consul Deployment
Guide for more information on configuring
the Consul agent to connect to the cluster deployed for Vault storage.
Enable and start the Consul service
Enable the systemd consul.service
unit to allow the Consul service to start.
Start the Consul service.
Check the status of the Consul service to ensure it is running.
Create a Vault service ACL token
In order to coordinate high-availability and write to Consul storage, the Vault service requires a Consul ACL token.
Create a file, vault-service-policy.hcl
, with the necessary ACL policy:
Create the ACL policy on the Consul cluster using a management token:
Create an ACL token using that policy:
Copy the SecretID
that is output from the previous step, and use it in the
Consul storage configuration for Vault described below.
Configure Vault
Vault may be configured by editing the /etc/vault.d/vault.hcl
file included
with the installation package. Refer to the Vault Configuration
Overview for additional details
about each setting.
Base configuration
The core required configuration values for Vault are cluster_addr
, api_addr
,
and listener
. The configuration below tells vault to advertise its local IPv4
address for internal communication, and to listen to TCP port 8200 on all
network interfaces using the TLS configuration files specified.
Storage configuration
To configure Consul storage, use the following Vault configuration stanza using the Vault service ACL token created in a previous step.
Auto-unseal
If you are using a supported cloud provider or have access to a supported
hardware security module (HSM),
you can enable auto-unseal using the seal
configuration stanza.
To use AWS KMS for auto-unsealing securely, your EC2 instances should have
appropriate permissions to a KMS key via their instance profile. See the
awskms
seal documentation
for full details of the configuration options and necessary permissions.
Vault Enterprise license
Note
This section applies only to Vault Enterprise.
Beginning with Vault 1.8, an Enterprise license file must exist on disk and be readable by the Vault service.
Copy your Vault Enterprise license file to /opt/vault/vault.hclic
. Then set
the file's group ownership to allow the Vault service to read the file.
Set the file permissions to allow the Vault service to read the file, but no other users to access the file.
Add the path to the Enterprise license file to /etc/vault.d/vault.hcl
.
Vault web UI
To enable the Vault web UI, set the ui
configuration value to true
.
Enable and start the Vault service
Enable the systemd vault.service
unit to allow the Vault service to start.
Start the Vault service.
Check the status of the Vault service to ensure it is running.
Check the status of Vault
To ensure Vault is running, you can use the vault status
command.
To ensure TLS connection can be validated, first set the VAULT_CACERT
environment variable to the path of the CA root certificate.
Then use vault status
to see the status of the local Vault server.
Initialize Vault
If this is the first time you are running this cluster, Vault will need to be initialized on one host before Raft clients can be joined.
Take note of these values and store them securely. You will need them to manually unseal Vault and to perform initial setup.
Unseal Vault
If you configured auto-unseal, Vault should unseal automatically. Use the
vault status
command to check whether Vault is sealed.
If Vault is sealed, use the vault operator unseal
command on each host
in the cluster with the unseal keys you received when initializing Vault
to unseal it.
Repeat the unseal command with new keys until the unseal progress is complete and Vault is unsealed.
Additional configuration
Audit Logging
Vault provides audit logging via Audit devices which serialize details of each request and response Vault handles. These logs may be stored to a file on disk, or sent to syslog or any socket endpoint.
Learn more about using audit logs to monitor and secure your Vault deployment with the Monitor Telemetry & Audit Device Log Data tutorial.
Replication
Vault Enterprise supports replication functionality to support performance and disaster recovery use cases. There are a number of tutorials and other documentation to explain the concepts and provide details about configuring these replication modes.
- Vault Enterprise Replication
- Vault Replication Internals
- Setting Up Performance Replication
- Disaster Recovery Repication Setup
- Monitoring Vault Replication
Resource Quotas
Vault provides tools for establishing lease count limits (Enterprise only) and request rate limits to avoid systemwide denial-of-service. Learn more about the concepts and capabilities behind Vault resource quotas in the Resource Quotas concepts documentation, and discover how to enable and manage resource quotas in the Protecting Vault with Resource Quotas tutorial.
Telemetry
The telemetry
stanza specifies various configurations for Vault to publish
metrics to upstream systems. Vault supports sending telemetry to a number of
systems including Circonus, DogStatsD, Prometheus, Stackdriver, Statsite, and
any statsd-compatible endpoint.
Review the telemetry configuration section of our documentation for details on configuring Vault telemetry for your provider, and learn more about Vault's telemetry collection and which metrics are collected in the telemetry internals documentation.
You can also learn more about using telemetry to monitor Vault on our Monitor Telemetry & Audit Device Log Data tutorial.