HCP Consul security overview

This topic provides an overview of network security considerations when using HCP Consul Dedicated or HCP Consul Central. By default, Consul deployments communicate securely across all protocols and user interactions. To enforce security, Consul uses gossip encryption, transport layer security (TLS) encryption, and access control lists (ACLs).

To learn more about what makes Consul secure and potential security threats, refer to Core security model in the Consul documentation.

Introduction

Consul has several mechanisms to ensure network security that function regardless of whether you use HCP Consul Dedicated or self-managed Community and Enterprise clusters with HCP Consul Central. The following mechanisms ensure that communication within a Consul cluster's service mesh can only take place between valid hosts:

• Gossip encryption
• Transport Later Security (TLS) encryption
• Access Control List (ACL) system

The HashiCorp Cloud Platform (HCP) provides additional features to improve network security. The following features are available:

• HashiCorp Virtual Network (HVN) peering
• Private cluster accessibility
• IP allowlist

Once a cluster is connected to HCP, it can be accessed and controlled using global management tokens that are accessible through the HCP portal. Configuring roles within your HCP organization is critical to preventing unwanted access to your network.

HCP Consul Dedicated does not automate the process to configure service intentions. After registering services with the Consul servers, you should create service intentions to ensure that only authorized services can communicate within the service mesh. Refer to service intentions overview for more information.

Gossip encryption

Consul uses a gossip protocol to manage membership and broadcast messages to the cluster. Intra-cluster communication is secured with a key that Consul agents use for authentication over the protocol.

When using HCP Consul Dedicated clusters, this key is generated for you and included in the client configuration you use to deploy clients. Keep this configuration secure to avoid unwanted access to the gossip pool.

For self-managed Community and Enterprise clusters, you can interact with and rotate gossip keys using either the consul keyring CLI command or the /operator/keyring endpoint.

To learn more, refer to Gossip protocol in the Consul documentation.

Transport Layer Security (TLS) encryption

Consul uses TLS encryption to secure communication between agents. A built-in certificate authority allows you to create, distribute, and rotate X.509 certificates so that agents and proxies in the service mesh send only verified requests to services.

HCP Consul Central automatically creates, manages, and rotates TLS certificates for HCP Consul Dedicated clusters and self-managed Community and Enterprise clusters linked to HCP Consul Central. Consul stores certificates in a secure HCP Consul Dedicated Vault environment. Certificates automatically expire after one year.

You can check the expiration for a TLS certificate on a self-managed Community or Enterprise cluster in the cluster details view.

To learn how to manually configure a cluster's TLS encryption, refer to the Secure Consul agent communication with TLS encryption tutorial.

Access Control Lists (ACLs)

Consul uses an ACL system to secure access to cluster data during user and agent requests. The ACL system consists of the following configurable components:

• ACL token
• ACL policy
• ACL role

The ACL system is always enabled when using HCP Consul Dedicated. For both HCP Consul Dedicated clusters and self-managed Community and Enterprise clusters linked to HCP, HCP Consul Central has access to an ACL token with a global management policy for the cluster. This token gives HCP Consul Central full read and write privileges for administering the cluster, which allows you to manage your clusters from a centralized platform.

HCP also creates an ACL token every time you generate an admin token to access a HCP Consul Dedicated cluster.

The tokens that HCP Consul Dedicated creates and has access to are stored in a secure HCP Consul Dedicated Vault environment.

You can create and manage ACL tokens using the consul acl CLI command, the /acl API endpoint, or a cluster's Consul UI. You can access the Consul UI for HCP Consul Dedicated clusters and self-managed Community and Enterprise clusters linked to HCP Consul Central directly through the HCP platform.

Do not modify the management token that is created when you link a self-managed Community or Enterprise cluster. In the event of a disaster, a modified management token may prevent recovery.

Be sure to configure your HCP organization's user roles to ensure that only authorized users have access to clusters through HCP. Refer to user roles and ACL policies for more information about the ACL policies linked to each user role. For more information about configuring roles in your organization, refer to Users.

HashiCorp Virtual Network (HVN) peering

An HVN is an essential networking component when using HCP Consul Dedicated clusters. With a peering connection or a transit gateway attachment between an HVN and a VPC or VNet, servers in HCP Consul Dedicated environments can establish secure connections with services hosted in user-managed environments.

You can connect an HVN to either an AWS or an Azure environment. You cannot deploy a product across multiple HVNs or change HVNs after you create them. To create multi-cloud deployments, establish a cluster peering connection between two HCP Consul Dedicated clusters with separate HVNs peered to separate cloud environments. These clusters must also have a compatible network topology in order to establish a connection between them.

Refer to HashiCorp Virtual Network for more information about using HVNs.

Private cluster accessibility

When you create an HCP Consul Dedicated cluster, you have the option to choose between private and public accessibility.

Private clusters do not expose their endpoint to the public internet. Only connected networks can communicate with the cluster through HTTPS or gRPC. Private clusters are more secure than public clusters. We recommend using private clusters in production environments.

Public clusters have an HTTP endpoint that can be accessed by any connection outside your network. We recommend only using public clusters for development, testing, and debugging purposes.

IP allowlist

HCP Consul Dedicated clusters can use an IP allowlist to restrict communication to a set of IPV4 address ranges. Address outside the ranges in the list are denied access to the cluster's network. This configuration provides an additional layer of security for securing Consul deployments with cluster peering connections. Refer to secure cluster access with IP allowlist for more information.

Service intentions

Service intentions are a mechanism for securing L4 and L7 traffic in a service mesh with identity-based enforcement. When you create a service intention, Envoy proxies check incoming requests against a set of user-defined rules, then allow or deny access accordingly.

HCP Consul Dedicated does not configure service intentions for clusters. When you link a self-managed Community or Enterprise cluster to tHCP Consul Central, existing service intentions are not changed.

For more information, refer to Service intentions overview in the Consul documentation. For specifications and example configuration entries, refer to Service intentions configuration entry reference.