HCP Consul security overview

This topic provides an overview of network security considerations when using HCP Consul. 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 HashiCorp-managed or self-managed clusters with HCP Consul. 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 Consul, 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 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 HashiCorp-managed 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 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 HashiCorp-managed clusters deployed with HCP Consul and self-managed clusters linked to HCP Consul Central. Consul stores certificates in a secure HashiCorp-managed Vault environment. Certificates automatically expire after one year.

You can check the expiration for a TLS certificate on a self-managed 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. For both HashiCorp-managed clusters and self-managed 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 HashiCorp-managed cluster.

The tokens that HCP Consul creates and has access to are stored in a secure HashiCorp-managed 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 HashiCorp-managed clusters and self-managed 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 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 HashiCorp-managed clusters. With a peering connection or a transit gateway attachment between an HVN and a VPC or VNet, servers in HashiCorp-managed 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 HashiCorp-managed 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 a HashiCorp-managed 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

HashiCorp-managed 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 does not configure service intentions for HashiCorp-managed clusters. When you link a self-managed 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.