Consul 1.9, HashiCorp’s service discovery cum service mesh tool, has left the beta phase behind, making mesh visualisation and application-aware intentions available to all.

Intentions are Consul’s access control definitions for services, and have been based on connections as provided by Layer 4 protocols in earlier versions of the project. This approach is a bit all or nothing, however, which is why the Consul team added application-aware intentions as a way to realise a more granular access control. 

The new addition allows the system to consider layer 7 (the application layer, hence the name) information like HTTP paths and methods when authorising HTTP-based communication between services, which is something the old intentions couldn’t access. 

In a call to DevClass, HashiCorp’s director of marketing Raymond Austin gave the example of using HTTP header information to allow put requests only, or to prevent a certain kind of browser from accessing some development path.

The second highlight of the release is an integrated way to visualise the services within a mesh and provide information about communication flow and the like. Teams already familiar with Consul will know that the tool had integrations with performance monitoring services for a while now. However, according to Austin the company’s customers “want out-of-the-box visualization as a way to just get started” and prefer it coming out of Consul directly rather than through a third party tool.

“The approach that we are taking from a visualization perspective is to try to be as easy to use as possible,” Austin tells us, since those things tend to get complicated rather quickly. 

Consul’s visualisation focuses on the service level, showing “multiple services that are communicating to each other” to get a quick overview. 

More information is available, but again relies on tools like Prometheus. “We work with metrics providers [..] to deliver a number of application centric metrics, like requests per second, error rate, and latency to allow users to drill down on each of the different services to figure out [..] what’s going on,” Austin explains.

This being 2020, the Consul team also spent some time working on ways to make their tool play nicely with container orchestrator Kubernetes. For example, there’s now a way to manage Consul service mesh configuration for services via custom resource definitions and, since HashiCorp users seem to be drawn to OpenShift, installing Consul on Red Hat’s Kubernetes distribution has become easier. 

Enterprises with large Consul client fleets will also be able to profit from a less CPU and bandwidth-hungry way of notifying the system of health status changes.

Even though the update isn’t a major one, admins are advised to take a look at the release notes, since Consul 1.9 comes with quite a few changes that might lead to problems with existing setups. Amongst other things, intention destinations in the connect component can no longer be reassigned and the default gateway port has become 8443 “to avoid assumption of Envoy running as root”. 

Component updates might be necessary since Consul stopped working with Envoy versions 1.12.0, 1.12.1, 1.12.2, and 1.13.0, and Raft protocol v2. An internal upgrade to Sentinel 0.16 in Consul Enterprise might lead to minor hiccups, since HashiCorp worked on its wording, turning whitelists into allowlists and blacklists into denylists in this version of the policy framework. 

Enterprise users should consider an update in any case, since v1.9 also includes a fix for CVE-2020-25201, which could lead to infinite raft writes and therefore a denial of service.