HashiCorp Consul 1.2: Service Mesh

We are excited to announce the release of HashiCorp Consul 1.2. This release supports a major new feature called Connect that automatically turns any existing Consul cluster into a service mesh solution. Connect enables secure service-to-service communication with automatic TLS encryption and identity-based authorization.

Consul is currently deployed on millions of machines worldwide. After upgrading to Consul 1.2 and enabling Connect, any existing cluster will instantly become a service mesh solution that works on any platform: physical machines, cloud, containers, schedulers, and more.

»Modern Service Networking with Service Mesh

A service mesh is necessary for organizations adopting microservices and dynamic cloud based infrastructure. Traditional host-based network security must be replaced with modern service-based security to accommodate the highly dynamic nature of modern runtime environments.

A service mesh provides a highly available, distributed solution to three critical problems:

• Discovery: Services must be able to find each other.
• Configuration: Services must accept runtime configuration from a central source.
• Segmentation: Service communication must be authorized and encrypted.

Up until this release, Consul solved the discovery and configuration use cases with DNS for discovery and K/V for configuration. Connect now solves the segmentation use case. All three of these features work together to provide a complete service mesh solution that works on any platform.

»Consul Connect

Connect is a major new feature in Consul that provides secure service-to-service communication with automatic TLS encryption and identity-based authorization. The Connect feature announced today is fully free and open source. Connect is available in Consul 1.2 as a public beta feature.

Connect was built with ease-of-use in mind. It can be enabled with one configuration option, and adding a single extra line to service registration automatically enables any existing application to accept Connect-based connections. Certificate rotation is automatic and causes no downtime. Connect requires only a single binary for all necessary subsystems. And many other features we'll cover later.

While easy to use, Connect exposes a lot of new functionality for Consul. We'll go into detail about some of these features later in this post, but first we'll enumerate all of the major new functionality of Consul with Connect:

• Encrypted Traffic: All traffic is established with Connect via mutual TLS. This ensures that all traffic is encrypted in transit. This allows services to be safely deployed in low-trust environments.

• Connection Authorization: Allow or deny service communication by creating a service access graph with intentions. Unlike a firewall which uses IP addresses, Connect uses the logical name of the service. This means rules are scale independent; it doesn’t matter if there is one web server or 100. Intentions can be configured using the UI, CLI, API, or HashiCorp Terraform.

• Proxy Sidecars: Applications can use a lightweight proxy sidecar process to automatically establish inbound and outbound TLS connections. This enables existing applications to work with Connect without modification. Consul ships with a built-in proxy that doesn't require external dependencies, along with third-party proxies such as Envoy.

• Native Integration: Performance sensitive applications can natively integrate with the Consul Connect APIs to establish and accept connections without a proxy for optimal performance and security.

• Layer 4 vs. Layer 7: Identity is enforced at layer 4. Consul delegates layer 7 features and configuration to a pluggable data layer. You can integrate with third-party proxies, such as Envoy, for features such as path-based routing, tracing, and more, while leaning on Consul for service discovery, identity, and authorization.

• Certificate Management: Consul generates and distributes certificates using a certificate authority (CA) provider. Consul ships with a built-in CA system that requires no external dependencies, integrates with HashiCorp Vault, and can also be extended to support any other PKI system.

• Certificate Rotation: Connect can automatically rotate both root and leaf certificates. Root rotation uses certificate cross-signing to ensure that old and new certificates can co-exist during the rotation period so there are no service interruptions. This system also enables a new CA provider to be configured seamlessly.

• SPIFFE-based Identities: Consul uses the SPIFFE specification for service identity. This enables Connect services to establish and accept connections with other SPIFFE-compliant systems.

• Network and Cloud Independent: Connect uses standard TLS over TCP/IP. This allows Connect to work on any network configuration as long as the IP advertised by the destination service is reachable by the underlying operating system. Further, services can communicate cross-cloud without complex overlays.

»Automatic Proxy Sidecars

Applications can use a proxy sidecar for establishing inbound and outbound connections without having to modify the original application. After enabling Connect, a one-line change to any service registration can enable that service to accept Connect-based connections:

{
  "service": {
    "name": "web",
    "port": 8080,
    "connect": { "proxy": {} }
  }
}

The only difference is the line starting with "connect". The existence of this one-line change configures Consul to automatically start and manage a proxy process for this service. The proxy process represents that specific service. It accepts inbound connections on a dynamically allocated port, verifies and authorizes the TLS connection, and proxies back a standard TCP connection to the process.

For upstream dependencies, a few more lines will configure a listener to proxy connections to a service over Connect. For example, if our "web" service needs to communicate to a "db" service over Connect:

{
  "service": {
    "name": "web",
    "port": 8080,
    "connect": {
      "proxy": {
        "config": {
          "upstreams": [{
             "destination_name": "db",
             "local_bind_port": 9191
          }]
        }
      }
    }
  }
}

This configures the managed proxy to setup a local-only listener on port 9191 to proxy to any remote "db" service. By reconfiguring "web" to use this local port, all communication between "web" and "db" will be encrypted and authorized.

Notice that throughout these examples, the original application "web" remains unmodified and unaware of Connect. With only one to a handful of lines of configuration, any application can accept and establish Connect-based connections using automatically managed sidecar proxies.

To learn more, read the reference documentation for proxies. If an application has extremely high performance requirements, an application can natively integrate with Connect. This allows a service to not require a proxy at all.

»Easy Development Connections

For optimal security, services should aim to accept only Connect-based connections. However, this introduces the challenge of connecting to services for development or testing purposes. Consul provides an easy to use consul connect proxy command for running a local proxy for establishing connections to services via Connect.

Consider an example scenario where there is a PostgreSQL server running that accepts connections only via Connect, and an operator wishes to connect using psql to this database for maintenance purposes. The operator can connect via psql using their local machine by using the consul connect proxy command:

$ consul connect proxy -service mitchellh -upstream postgresql:9191
==> Consul Connect proxy starting...
    Configuration mode: Flags
               Service: mitchellh
              Upstream: postgresql => :9191
       Public listener: Disabled
...

And from another shell, they can connect using standard psql:

$ psql -h 127.0.0.1 -p 9191 -U mitchellh mydb
> 

The -service flag represents the identity of the source. The service doesn't need to exist, but the caller must have a valid ACL token to register this service and Consul must be configured to allow connections between the source and destination.

Local development and testing with remote services is a common workflow challenge for service mesh that is extremely simple with Consul and Connect.

»Access Control with Intentions

Access control between services is configured with "intentions." An intention is an allow or deny rule between a single source and destination. Intentions can be created via the UI, CLI, API, or Terraform.

Following the example above, to allow all access to the db service from web:

$ consul intention create -allow web db
Created: web => db (allow)

The "web" service is allowed to communicate to "db". The intention can then be updated to -deny to instantly disable connections between the two services.

Intentions can be managed separately from service deployment, and ACL rules can be configured so that people can only modify intentions for specific services. This allows security and segmentation to be configured and controlled dynamically in near real-time.

»Learn More & The Future

We're excited about Consul 1.2 and the major new functionality it supports. Due to the size and impact of the feature, Connect should be considered beta for Consul 1.2. We'll be working hard through the summer on Connect and hope to remove the beta tag before the end of the year.

In the future, we'll also be building more functionality for Connect, including new UI enhancement, support for Envoy as a proxy, integrations with Nomad and Kubernetes, and more. We're just getting started with Connect in Consul 1.2.

To download Consul 1.2, visit https://www.consul.io/.

The following pages are good next steps for learning more:

• Feature Homepage - This is the dedicated homepage for Connect within Consul and contains an overview of the features it provides and links to get started.

• Connect Intro step - The intro guide has been extended with a step introducing Connect and includes a walkthrough for using Connect in just a few minutes.

• Connect Interactive Tutorial - This is an interactive tutorial to walk you through the key steps of running Connect.

• Connect Reference Docs - The reference documentation for Connect contains all the details on how Connect works, proxies, native integrations, certificate management, and more. This is recommended reading prior to deploying Connect.

• Connect Security Checklist - Connect has a different security expectation than the rest of Consul. To operate securely, we recommend reviewing this checklist and reading and understanding the threat model of Consul.

• Connect Production Guide - This is a complete guide to configuring a Consul cluster for Connect in production, including all the necessary steps for a fully secured configuration.

• Connect Whiteboard Session - This video made by founder and co-CTO Armon Dadgar introduces the Connect features for network management, security, and performance.