Skip to main content
In its default state, Consul transmits all RPC, API, Raft, and Gossip traffic in clear text. To harden your Consul deployment, enable and configure each of the following security components:
ComponentPurposeConfiguration Example
Gossip Protocol EncryptionEncrypt Serf membership and failure-detection trafficencrypt = "BASE64_KEY"
Built-in ACL SystemEnforce fine-grained access control on KV store and APIs"acl": { "enabled": true, ... }
Consul Agent TLSSecure agent-to-agent RPC and HTTP API"tls_cert_file": "/path/to/agent.crt", ...
Mutual TLS (mTLS)Encrypt and authenticate service-to-service communicationEach service presents and verifies certificates
Certificate Authority (CA)Issue and rotate certificates via Consul or external CA (Vault)consul tls cert create -server
The image is a slide titled "Consul Security/Threat Model," describing various methods Consul uses to secure communication, including Gossip protocol, ACL system, Consul agent, mTLS, and acting as a CA.

​
1. Gossip Protocol Encryption & ACL System

Consul uses Serf’s Gossip protocol for intra-cluster membership and failure detection. Without encryption, Serf messages are vulnerable to eavesdropping or injection.
If you skip Gossip encryption, all Serf traffic (including cluster health checks) is sent in clear text.

​
Enable Gossip Encryption

Add a shared symmetric key to every server and client configuration: 
# consul.hcl
encrypt = "BASE64_ENCRYPTION_KEY"

​
Enable the ACL System

By default, ACLs are disabled. Turning them on enforces policies for KV operations and API endpoints: 
{
  "acl": {
    "enabled": true,
    "default_policy": "deny",
    "down_policy": "extend-cache"
  }
}
The image is a slide titled "Consul Security/Threat Model," discussing the Gossip Protocol and ACL System, highlighting their features and objectives. It includes colorful text and a pixelated design on the right side.

​
2. Consul Agent TLS

Securing agent-to-agent communication is critical when running in untrusted networks or across cloud regions. Consul agents can use TLS certificates for both RPC (Raft, Serf) and the HTTP API. Add the following to each agent’s JSON or HCL configuration: 
{
  "tls_cert_file": "/path/to/agent.crt",
  "tls_key_file":  "/path/to/agent.key",
  "tls_ca_file":   "/path/to/ca.pem"
}
Consul will verify peer hostnames on incoming connections. Ensure your certificate’s Common Name (CN) or SAN matches the agent’s advertised address.

​
3. Mutual TLS (mTLS)

mTLS provides both encryption and peer authentication, forming the backbone of Consul’s Service Mesh:
  • Services present client certificates issued by a trusted CA.
  • Peers validate each other’s certificates before establishing an encrypted channel.
  • Identity information (e.g., service name) is embedded in the certificate and used for authorization.
The image is a slide titled "Consul Security/Threat Model," detailing features of the Consul Agent and mTLS for encrypting communications and validating authenticity.

​
4. Certificate Authority Integration

Consul can act as its own CA or delegate certificate issuance to an external CA such as HashiCorp Vault. Centralized certificate management simplifies rotation and revocation.

​
Using the Built-in CA

# Generate server cert
consul tls cert create -server

# Generate client cert
consul tls cert create -client

# Generate CLI cert
consul tls cert create -cli

​
Delegating to Vault (or other CA)

# consul.hcl
certificate_authority = {
  provider = "vault"
  options = {
    address = "https://vault.example.com"
    token   = "VAULT_TOKEN"
    # additional Vault settings…
  }
}
When integrating with Vault, configure ACL tokens and policies to allow Consul to request and renew certificates automatically.
By enabling Gossip encryption, the ACL system, agent TLS, mTLS, and CA integration, you secure every layer of Consul’s communication—from cluster membership and Raft consensus to HTTP APIs and service-to-service traffic in the mesh.

Watch Video