Secure Consul

Consul is not secure by default, but can be configured to satisfy the security requirements for a wide-range of use cases from local developer environments without any configuration, to container orchestrators in-production with ACL authorization, and mTLS authentication.

Requirements and recommendations for configuring and operating a secure Consul deployment may vary drastically depending on your intended workloads, operating system, and environment. This document provides an high level description of the Consul security model and features intended to harden your environment.

If you are looking for documentation on how to secure service-to-service communication within a service mesh using Consul, refer to Connect workloads to Consul service mesh and Secure service mesh overview.

Consul security model

Security models overview is a good starting point to understand what are the recommended configurations that help you increase Consul's security. The requirements highlighted in Threat model offer guidance on sensitive areas of your Consul installation that need to be addressed.

The table below provides a simplified overview of different Consul operations and the Consul feature responsible of their security.

Traffic encryption

Consul allows to use encryption in all the network communications between the different agents and also for the Consul API, CLI, and UI interfaces.

Two distinct encryption systems are available to secure Consul, depending on the traffic they are encrypting, Gossip encryption and Mutual TLS (mTLS) encryption.

Gossip encryption

Consul uses a gossip protocol to perform the following cluster operations:

• Identify datacenter members.
• Quickly detect failed members and notify the rest of the cluster.
• Broadcast events and queries that can trigger custom workflows.

The gossip protocol, as well as its membership management and message broadcasting features, use the Serf library.

Enabling gossip encryption for your Consul datacenter secures all the traffic broadcasted by the agents to maintain cluster health state.

To learn more about enabling gossip encryption on your Consul datacenter and rotating gossip keys, refer to manage gossip encryption.

mTLS encryption

Consul uses several communication protocols over different ports that you can secure using mTLS:

• A consensus protocol to provide data consistency between Consul servers.
• Remote Procedure Calls (RPC) forward requests from client agents to server agents.
• An HTTP or HTTPS interface to permit client communication with the Consul API, CLI, and UI.
• A gRPC interface to receive incoming traffic from the gateways and Envoy proxies registered to the agent node.

Consul uses mTLS to verify the authenticity of server and client agents. It requires that all clients and servers have key pairs that are generated by a single Certification Authority (CA). We recommend using a private CA that is not shared with other applications.

To learn more about enabling mTLS on your Consul datacenter, refer to Manage mTLS encryption.

Access control

Consul implements an Access Control List system (ACL) to authenticate requests and authorize access to resources. ACL also control access to the Consul UI, API, and CLI, as well as secure service-to-service and agent-to-agent communication.

To learn more about the ACL system refer to the Access control list (ACL) documentation.

Additional security best practices

Enabling script checks via the enable_script_checks configuration setting may introduce a remote execution vulnerability that is known to be targeted by malware. We strongly recommend using enable_local_script_checks instead. See this blog post for more details.

Configure client agents to bind to localhost for the HTTP, HTTPS, DNS, and gRPC APIs. This ensures these APIs are not exposed outside the node where the client agent is running. Consul client agents bind to localhost by default if the addresses and client_addr config options are not specified.

Verify that the version of Consul deployed within the environment does not have any active CVEs that are relevant by visiting the following page: Hashicorp Discuss: Consul Security

Leverage Consul intentions within a service mesh for defining rules which allow service-to-service communication.

Other resources

Automate security configuration with auto_config

Configuring traffic encryption, both for gossip and mTLS, and creating agent ACL tokens involves many operations that needs to be manually executed by an operator. You can automate those operation by using auto_config. Read more on this at Consul auto-config on Docker.

Implement Single Sign On (SSO)

Instead of creating user tokens, you can use an OIDC provider to implement Single Sign On (SSO) on Consul. This simplifies the integration of Consul in your network and avoids the creation of ad-hoc credentials for every new user. Read more on this at Enable Auth0 single sign-on (SSO).

Monitor API request with audit logging EnterpriseEnterprise

Consul Enterprise offers advanced monitoring for its HTTP API endpoints. Using audit logs it is possible to capture a clear and actionable log of authenticated requests performed against Consul API. Read more on this at audit logging.

Separate resources and delegate permissions with namespaces EnterpriseEnterprise

Namespaces provide separation for teams within a single organization enabling them to share access to one or more Consul datacenters without conflict. Additionally, namespaces with ACLs allows you to delegate access control to specific resources within the datacenter including services, Connect service mesh proxies, key/value pairs, and sessions. Read more on this in the namespaces documentation.