We are pleased to announce the public beta availability of HashiCorp Consul 1.8. Consul is a multi-cloud service networking platform to connect and secure services across any runtime platform and public or private cloud.
Consul 1.8 adds features that lower the barrier to entry for adopting a service mesh in heterogeneous environments. To achieve this, organizations can integrate any service into a service mesh without adding manual overhead and extend that mesh to both Kubernetes and non-Kubernetes environments in any region or cloud. Additionally, this release adds new enterprise features that allow identity-based authentication, and help fulfill compliance requirements through operational traceability.
This release includes the following features:
- Ingress Gateway: Provides a quick on-ramp path to allow applications that reside outside the service mesh to communicate with services within the mesh.
- Terminating Gateway: Allows applications that reside within the service mesh to communicate with existing services outside of the mesh.
- WAN Federation over Mesh Gateway: Simplifies multi-cluster and multi-datacenter Consul environments (federated datacenters) by sending all cross-environment traffic through the Mesh Gateways instead of requiring all Consul servers to be exposed across networks.
- Audit Logging (Consul Enterprise only): Provides a way for security administrators to clearly capture all user actions made in a Consul cluster to fulfill compliance requirements, and carry out risk assessments.
- Single Sign-On (Consul Enterprise only): Enables operators to delegate identity authentication to browser-enabled SSO providers (e.g. Okta). Allows users to self-serve ACL tokens to manage constructs within Consul (groups of services, namespaces, KV, central config, etc.), Provides a workflow to provision tokens for services and users based on SSO identity.
NOTE: This beta release does not have a forward compatibility guarantee and certain functionality may change, that might cause it to be incompatible with the General Availability release. We recommend that you only use the beta releases to test functionality and upgrades with clusters that can be lost.
» Ingress Gateway
Typically when adopting a service mesh technology, practitioners find that the onboarding and migration process for applications takes time, and occurs in a phased manner. During this migration, applications that reside within physical or virtual datacenters communicate with applications within the mesh through a gateway that allows the traffic to the upstream service (i.e. the service that eventually responds to the request).
The Ingress Gateway capability in Consul provides operators a quick and easy ingress solution to start transitioning services to the Consul service mesh.
In this release, the
consul connect envoy command now includes ‘ingress gateway’ as a new option. This enables running an Envoy instance that is configured to expose a dynamic subset of Consul services to consumers outside the mesh through a single ingress point. Ingress gateways enable incremental migration towards a service mesh architecture without requiring explicit networking overrides or requiring the overhead of additional service capacity.
Consul ingress gateways can optionally be configured to present a Consul-generated TLS certificate for encrypting traffic. This will allow external services to negotiate a trusted TLS connection with the ingress gateway if they trust the Consul certificate authority. Ingress gateways can also be a point where intentions are applied, furthering the application of security policies within a Consul service mesh.
Since ingress gateways are a part of the Consul service mesh, they also function as a logical point where you can apply Layer 7 traffic policies such as splitting, routing, or host-based paths. This enables Consul to drive progressive delivery use cases for practitioners concerned with managing application lifecycles.
» Terminating Gateway
A Consul service mesh provides automatic, encrypted communication between services over mTLS. The service-to-service connections are controlled by intentions, which determine whether one service can connect to another. Intentions simplify network security since segmentation is based on service identities instead of ephemeral source/destination IPs.
Organizations will often transition to a service mesh incrementally due to outside constraints or a lack of infrastructure automation. In this scenario users may be operating services inside and outside the mesh for long periods of time as they transition. There are also cases where certain services will never be inside the mesh.
In these inevitable hybrid deployments, services in the mesh currently need to connect to external services directly. This is a degraded user experience — different services are discovered in different ways, not all connections are encrypted with mTLS, and intentions only control a subset of connections.
In this release, the Consul service mesh capabilities support creating a terminating gateway. Terminating gateways are egress proxies that terminate Connect mTLS connections, enforce intentions, and forward requests to appropriate destination services.
» WAN Federation over Mesh Gateway
Applications are rarely all deployed into a single homogenous environment. More often, workloads and applications are deployed across multiple heterogeneous platforms, networks, and datacenters.
Consul supports these complicated topologies. It enables operators to deploy separate Consul datacenters and join these datacenters together via federation.
With Consul 1.8 the new WAN Federation Via Mesh Gateway feature reduces the operational burden of joining datacenters together. Prior to this release, service-to-service traffic between datacenters would be routed over Mesh Gateways that sit at the edge. In addition, Consul control-plane communication between datacenters required that each Consul server was also deployed at the edge. With the WAN Federation enhancements implemented in Consul 1.8, we enable the ability to have Mesh Gateways handle the traffic for all communication, including the WAN Gossip traffic. Since traffic is behind these gateways, Consul can handle complex environments that may be isolated, exist behind complex NAT scenarios, or even leverage overlapping IP address spaces.
» Audit Logging
Note: This is a Consul Enterprise feature
As enterprise software, many of Consul’s users are subject to regulations like HIPAA, PCI, GDPR, and others. As a part of these regulations, Consul customers require a detailed record of events for all operations taken in the system.
In this release, Consul Enterprise includes the following audit logging capabilities:
- Clear, actionable, and JSON formatted log of authenticated events (both attempted and committed) taken by application or persons in Consul.
- Unambiguous regulatory compliance. Consul now provides operators and security personnel a detailed history of actions initiated within the system. These events contain a timestamp, the operation performed, and the user who initiated the action
» Single Sign-On
Note: This is a Consul Enterprise feature
Users traditionally authenticate and gain access to Consul using tokens, which are access identifiers that exist solely within Consul. However, many organizations desire to integrate Consul with their existing corporate authentication systems.
Single sign-on (SSO) enables operators to delegate identity authentication to browser-enabled OIDC providers (e.g. Okta) to allow users to self-serve ACL tokens to manage groups of services, namespaces, KV, central config, etc. Consul enterprise customers can now adopt the same workflow to provision tokens for services and users based on SSO identity.
The Consul 1.8 release enables an easier adoption path for service mesh and for adding enterprise governance requirements. We would like to thank our active community members who have been invaluable in adding new features, reporting bugs, and improving the documentation for Consul in this release. For more information on getting started using one of our gateway features (WAN Federation over Mesh Gateway), please refer to our learn website.