Configuring the Consul Storage Backend

In this guide, you’ll learn how to set up HashiCorp Vault to use Consul as its storage backend. Consul delivers a durable, highly available key–value store that scales independently, ensuring Vault’s data is stored reliably across clusters.

Why Choose Consul for Vault Storage

Consul offers robust features that enhance Vault’s resilience and scalability:

Feature	Benefit	Details
Durable KV Storage	High availability	Replicates data across 3–5 voting members for automatic failover.
Independent Scaling	Flexible capacity management	Scale Consul CPU and memory separately from Vault instances.
Built-in Integration	Service discovery & health	Vault registers itself in Consul for health checks and topology.
Automated Snapshots	Simplified backups	Create snapshots for backup and upgrades with minimal downtime.
Enterprise Support	Official HashiCorp support	Fully supported as a Vault backend in enterprise environments.

Running a dedicated Consul cluster adds maintenance overhead—setup, ACLs, upgrades, and monitoring. However, with proper automation, it operates with minimal intervention.

Cluster Topology

One Vault cluster ↔ One Consul cluster (no cross–data-center mixing)
Odd number of nodes (3 or 5) ensures reliable leader election
Leader nodes accept commits and replicate logs to followers

Dedicated Consul Cluster for Vault

To prevent resource contention and maintain performance, host Vault storage on a dedicated Consul cluster. Do not co-locate service discovery or mesh workloads on the same cluster.

AWS Deployment Example

The image illustrates the deployment of the Consul storage backend across three availability zones within a VPC, each containing a private subnet. It highlights a special installation of Consul using redundancy zones.

Distribute Vault and Consul nodes across multiple Availability Zones (AZs) in a VPC:

Vault servers deployed in each AZ for redundancy
Consul servers in each AZ, using enterprise Redundancy Zones

Even if an entire AZ becomes unavailable, both Consul and Vault remain operational.

Vault Nodes & Local Consul Agents

Vault servers run a local Consul agent in client mode. Each agent joins the cluster and handles all API requests, so Vault always points to localhost:

The image illustrates the deployment of a Consul storage backend with three Vault nodes, each communicating with a local Consul agent, connected to a Consul cluster.

This model removes the need to update Vault’s configuration when the Consul cluster membership changes.

Vault Configuration Example

Below is a sample HCL configuration for Vault using Consul as the storage backend:

storage "consul" {
  address = "127.0.0.1:8500"        # Consul API endpoint
  path    = "vault/"               # KV prefix for Vault data
  token   = "1a2b3c4d-1234-abdc-1234-1a2b3c4d5e6a"  # ACL token
}

listener "tcp" {
  address                  = "0.0.0.0:8200"
  cluster_address          = "0.0.0.0:8201"
  tls_disable              = false
  tls_cert_file            = "/etc/vault.d/client.pem"
  tls_key_file             = "/etc/vault.d/cert.key"
  tls_disable_client_certs = true
}

seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "12345678-abcd-1234-abcd-123456789101"
  endpoint   = "example.kms.us-east-1.vpce.amazonaws.com"
}

api_addr     = "https://vault-us-east-1.example.com:8200"
cluster_addr = "https://node-a-us-east-1.example.com:8201"
cluster_name = "vault-prod-us-east-1"
ui           = true
log_level    = "INFO"

Ensure the Consul ACL token has permissions scoped only to the vault/ path. Rotate tokens periodically to maintain security.

Consul Server Configuration Example

Place the following JSON in /etc/consul.d/server.json on each Consul server node:

{
  "log_level": "INFO",
  "server": true,
  "ui": true,
  "data_dir": "/opt/consul/data",
  "bootstrap_expect": 5,
  "encrypt": "xxxxxxxxxxxxxx",
  "retry_join": [
    "provider=aws tag_key=Environment-Name tag_value=consul-cluster region=us-east-1"
  ],
  "leave_on_terminate": true,
  "enable_syslog": true,
  "bind_addr": "10.11.11.11",
  "advertise_addr": "10.11.11.11",
  "client_addr": "0.0.0.0",
  "datacenter": "us-east-1",
  "acl": {
    "enabled": true,
    "default_policy": "deny",
    "down_policy": "extend-cache",
    "tokens": {
      "agent": "xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }
  },
  "key_file": "/etc/consul.d/cert.key",
  "cert_file": "/etc/consul.d/client.pem",
  "ca_file": "/etc/consul.d/chain.pem",
  "verify_incoming": true,
  "verify_outgoing": true,
  "verify_server_hostname": true
}

Customize addresses, data directories, and ACL tokens to fit your environment.

Watch Video

Demo Running Vault in Production

Configuring the Integrated Storage Backend

Introduction

Introduction to Vault

Learning the Vault Architecture

Installing Vault

Compare Authentication Methods

Create Vault Policies

Assess Vault Tokens

Compare and Configure Secrets Engines

Vault Agent

Vault Replication

Configuring the Consul Storage Backend

Why Choose Consul for Vault Storage

Cluster Topology

Dedicated Consul Cluster for Vault

AWS Deployment Example

Vault Nodes & Local Consul Agents

Vault Configuration Example

Consul Server Configuration Example

Further Reading

Watch Video

​Why Choose Consul for Vault Storage

​Cluster Topology

​Dedicated Consul Cluster for Vault

​AWS Deployment Example

​Vault Nodes & Local Consul Agents

​Vault Configuration Example

​Consul Server Configuration Example

​Further Reading

Watch Video

Why Choose Consul for Vault Storage

Cluster Topology

Dedicated Consul Cluster for Vault

AWS Deployment Example

Vault Nodes & Local Consul Agents

Vault Configuration Example

Consul Server Configuration Example

Further Reading