Consul 1.20 improves multi-tenancy, metrics, and OpenShift deployment

Consul 1.20 makes improvements for Kubernetes environments for both service discovery and service mesh use cases. Consul is a global service networking platform that provides multi-runtime service discovery and secure services networking. Version 1.20 focuses on improvements for Consul on Kubernetes, addresses onboarding in multi-tenant environments, improves observability for service registration, and tightens security for OpenShift deployments.

»Simplified service discovery onboarding in multi-tenant deployments

Consul on Kubernetes introduces Consul DNS views, an enterprise feature that improves the usability of service discovery in multi-tenant environments and also tightens security by allowing organizations to limit discovery between tenants. As a result, organizations can more easily adopt service discovery across different teams throughout the organization while ensuring clear security separation between tenants.

»Past challenges with admin partitions

In previous versions, a common challenge surfaced when existing customers enabled Consul admin partitions and started migrating their Kubernetes applications into different partitions. Developers had to update their applications to include partition names in any Consul DNS queries. This was not required prior to using admin partitions because all services resided in the same default partition and therefore application services did not need to specify the partition name in their Consul DNS queries. However, when admin partitions were enabled and services were migrated into new partitions, developers needed to update application services to include the partition information of target services in Consul DNS requests, otherwise Consul would assume the request was made for a target service residing in the default partition.

»The Consul DNS views solution

With Consul DNS views, developers who migrate from the default partition to a new partition no longer need to update their application services for Consul DNS queries within the same partition. Consul can now deploy a Consul DNS proxy pod in each partition that proxies all Consul DNS requests. The Consul DNS proxy appends partition metadata information from the requesting source service via an ACL token before forwarding to the Consul servers. With the source partition metadata included in the request, Consul will resolve the request in the context of that partition, rather than the default partition. As a result, developers do not need to alter their applications to include partition names in the DNS requests if both the requesting and target services reside in the same partition. This makes it much easier for organizations using Consul service discovery to migrate to a multi-tenant environment.

In addition, Consul DNS views also provides more security control. In previous versions, ACLs that affected Consul DNS were enforced at a Consul cluster level. It was not possible to grant different DNS permissions to different tenants. All tenants had the same access to the same records as permitted by the cluster-level DNS ACL policy. Consul DNS views now allows organizations to apply per-tenant DNS ACL policies, providing more fine-grained controls for service discovery.

The diagrams below illustrate a frontend service sending DNS queries to Consul in order to reach the api service. The Consul DNS proxy will append partition metadata in the query, which will ensure Consul returns the IP address for the api service in the appropriate partition.

»Improved Consul catalog sync metrics for Kubernetes

Consul 1.20 now includes improved metrics for Consul catalog sync, resulting in more visibility for operators. Consul catalog sync is a feature that automatically registers Kubernetes services with Consul’s catalog. Once registered, Kubernetes services can be discovered by other services in the Consul cluster, including non-Kubernetes services.

Prior to this enhancement, operators had limited visibility into the status of Kubernetes services being synced to Consul and the performance of the sync catalog process. At scale, it was difficult to discern if the sync process was healthy and progressing normally. Without status information or metrics, troubleshooting performance-related issues was difficult.

Catalog sync enhancements now provide more insights that include status and performance metrics of the sync process. New performance metrics include the rate of registered or deregistered services, the status and health of the sync process, and additional metadata related to registered services. As a result of this additional observability data, operators have a better understanding of the syncing process and are more equipped to troubleshoot issues.

»Hardened OpenShift integration

The latest Consul release includes a new hardened integration that allows organizations with strict security requirements to more easily deploy Consul service mesh onto OpenShift environments. Prior to this release, deploying Consul service mesh on Kubernetes required the transparent proxy to have elevated permissions, specifically the anyuid security context constraint (SCC) privileges. This prevented security conscious customers from deploying the transparent proxy in OpenShift environments where elevated pod permissions were prohibited. Consul on Kubernetes 1.20 no longer requires elevated permissions for the transparent proxy in OpenShift deployments. As a result, organizations can deploy Consul on Kubernetes without having to compromise on their security posture.

»Learn more about Consul 1.20

The latest Consul release provides several improvements for customers using Consul in Kubernetes environments. Consul DNS views removes friction for developers when migrating from single-tenant to multi-tenant environments for service discovery. This makes the adoption of admin partitions much easier across organizations. There are also enhancements for Consul catalog sync that provide operators with more insights into the health, status, and performance of service registration. Lastly, operators no longer need to provide elevated permissions to containers when using transparent proxy, resulting in tighter security in OpenShift deployments.

For details on Consul DNS views, please refer to the Consul DNS views on Kubernetes documentation.

Get started with HashiCorp Consul through our many tutorials for both beginners and advanced users. You can start a free trial with self-managed Consul Enterprise to test out commercial features like admin partitions and Consul DNS views.