Specifications
This topic describes the specifications and lists requirements for operating HCP Consul server clusters. Refer to Constraints and Known Issues for additional requirements.
Connecting to Consul
HCP Consul UI provides the URL and an admin token to access the Consul UI or to make API calls to the Consul server (under Access Consul in your cluster overview page). HCP Consul does not require you to specify any port number to access.
The following commands returns the trusted certificate authority (CA) root certificates for the HCP Consul cluster.
Maximum Latency
Consul uses the gossip protocol to share information across agents. To function properly, you cannot exceed the protocol’s maximum latency threshold.
The latency threshold is calculated according to the total round trip time (RTT) for communication between servers and clients.
For data sent from a Consul client to an HCP server agent:
- Average RTT for all traffic cannot exceed 50ms.
- RTT for 99 percent of traffic cannot exceed 100ms.
We recommend deploying Consul clients to the same region as your HCP Consul cluster's HVN to avoid potential cross-region network interruptions.
The following websites can help you determine latency between your HVN and workload regions where Consul client agents are deployed:
- AWS Latency Monitoring website. Contains for real-time information about AWS region latency.
- Azure network round-trip latency statistics. Contains updated information about Azure region latency.
Default Clusters and HVNs
The default number of HashiCorp virtual networks and Consul clusters depends on whether or not you use a trial version of HCP Consul.
| Resource | Trial Status | Non-trial Status |
|---|---|---|
| Number of HVNs | 3 | 3 |
| Number of Consul Clusters | 3 | 6 |
If you require additional resources, submit a request to Hashicorp support.
Security Model
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, refer to Security Models in the Consul documentation.
Gossip Encryption
Consul uses a gossip protocol to manage membership and broadcast messages to the cluster. Consul also uses an encryption key to secure the data that Consul agents exchange over the gossip protocol.
The gossip pool has several benefits, including:
- Automatic server discovery
- Distributed failure detection
- Fast and reliable event broadcasts
To learn more, refer to Gossip Protocol in the Consul documentation
Tutorial: To learn how to manually configure gossip encryption, complete the gossip encryption tutorial.
Transport Layer Security (TLS) Encryption
Consul uses a consensus protocol to elect a server as the cluster leader. When client agents forward remote procedure call (RPC) requests to servers, the leader is responsible for data consistency across the cluster.
Consul uses TLS encryption to secure these types of agent communications, verify the authenticity of servers and clients, and ensure the data has not been compromised. TLS certificates are stored securely.
You can find the public certificate in your HCP Portal. This certificate is required for the Consul clients to authenticate with HCP Consul servers.
To learn more, refer to the following topics in the Consul documentation:
Access Control Lists (ACLs)
Consul uses ACLs to securely access to cluster data during user and agent requests. You can configure ACLs in the HCP Portal, or by using API or CLI interactions. To learn more, refer to the Access Control List (ACL) Overview.
HCP Consul enables ACLs by default. You can generate a root token from the cluster overview, but you must create new policies and tokens to enact more granular control over access to the data.
Tutorials: To learn more about how to create and implement ACL tokens, complete the following tutorials: