Consul uses centrally managed service policies and configuration to enable dynamic routing and security based on service identity. These policies scale across data centers and large fleets without IP-based rules or networking middleware.

Service-to-service communication policy at Layer 7 can be managed centrally, enabling advanced traffic management patterns such as service failover, path-based routing, and traffic shifting that can be applied across public and private clouds, platforms.

Centrally managed service observability at Layer 7 including detailed metrics on all service-to-service communication such as connections, bytes transferred, retries, timeouts, open circuits, and request rates, response codes.

Unfortunately, Consul does not provide auditing for access requests that are permitted or denied from either an ACL or service intentions.

More information can be found on the general Consul site found here.

While the Consul snapshot agent can help create Consul snapshots based on a schedule and save them to external storage, such as Amazon S3 or Azure Blob Storage, it's a feature of Consul Enterprise and is not an open-source tool.

All Consul servers participate in the Raft consensus algorithm to ensure that transactions occur in a consistent, linearizable manner. Transactions modify cluster state, which is maintained on all server nodes to ensure availability in the case of node failure. Server nodes also participate in a WAN gossip pool with server nodes in other datacenters. Servers act as gateways to other data centers and forward traffic as appropriate. Information gathered from the -server flag explanation found here.

When federating clusters across multiple data centers using the WAN gossip pool, services are not registered in the local data center but are forwarded to the appropriate data center based upon the data center value in the query. See this link for additional explanation.

In this case, five servers are registered to Consul for the backend service, but Consul will only respond to queries against the service catalog with registered and healthy nodes for that service. In this case, it's possible that two of the backend instances were failing a health check; therefore, Consul responded with the three remaining healthy nodes.

https://developer.hashicorp.com/consul/docs/discovery/dns#standard-lookup

Once you create a new key and instruct Consul to install it across all server and client agents, you must indicate that the new key becomes the primary key to be used for encryption by using the command consul keyring -use TX/1dsj67x/4XdTeSG1Cb5RdC/cbAbv9Hch4H8cL8nk=. Only after Consul changes the primary encryption key can you remove the old encryption key from the key ring.

-----------------------------------------------------

Example:

https://developer.hashicorp.com/consul/commands/keyring

The anonymous token is used when a request is made to Consul without specifying a bearer token. The anonymous token's description and policies may be updated but Consul will prevent this token's deletion.

https://developer.hashicorp.com/consul/docs/security/acl#builtin-tokens

You can update service definitions without any downtime by changing the service definition file and sending a SIGHUP to the agent or running consul reload. Alternatively, you can use the HTTP API to add, remove, and modify services dynamically.

https://developer.hashicorp.com/consul/tutorials/developer-discovery/service-registration-health-checks

https://developer.hashicorp.com/consul/commands/reload

Reloadable Configurations

Once ACLs have been configured and you are requiring tokens to interact with Consul, there are two ways to set the token when interacting with Consul. You can provide the token on each command issued using the -token flag or you can set the CONSUL_HTTP_TOKEN environment variable, which appends the token to each command.

-------------------------------------------------------------------

Examples:

Setting the environment variable:

$ export CONSUL_HTTP_TOKEN=988b8fb4-357a-376d-057e-9d9fd5a170a2

Issuing the -token flag:

$ consul members -token=988b8fb4-357a-376d-057e-9d9fd5a170a2

-------------------------------------------------------------------

As an example of not setting the -token flag, check out this example. In the first command, I issue the consul members command, but Consul doesn't respond because ACLs are set to deny. In the second command, I provide the token and it responds with the members of the Consul cluster:

https://developer.hashicorp.com/consul/commands#consul_http_token

Intentions define access control for services via Connect and are used to control which services may establish connections. Intentions can be managed via the API, CLI, or UI.

Intentions are enforced by the proxy or natively integrated application on inbound connections. After verifying the TLS client certificate, the authorize API endpoint is called which verifies the connection is allowed by testing the intentions. If authorize returns false the connection must be terminated.

https://developer.hashicorp.com/consul/docs/connect/intentions

The join command tells a Consul agent to join an existing cluster. A new Consul agent may join any node in the existing cluster. After joining with one member, the gossip communication will propagate the updated membership state across the cluster.

An agent that is already part of a cluster may join an agent in a different cluster, causing the two clusters to be merged into a single cluster.

More information can be found here.