Consul 1.12 Hardens Security on Kubernetes with Vault

HashiCorp Consul 1.12 — now GA — represents yet another step forward in our effort to help organizations build a zero trust security architecture. For Consul on Kubernetes users, this release reduces Consul secrets sprawl and automates the rotation of Consul server TLS certificates by leveraging HashiCorp Vault, our enterprise secrets management solution. Additionally, Consul 1.12 helps users better understand their Consul datacenter status and access control list (ACL) system behavior.

What are your pain points?: See any opportunities for improvement in Consul? Or suggestions for post-1.12 changes to our ACL system or new Consul overview page? We’d love to hear from you.

»Secrets Management for Consul on Kubernetes Using Vault

Consul on Kubernetes can now centrally store all Consul secrets within HashiCorp Vault rather than as Kubernetes secrets. This ensures secrets are encrypted at rest with centralized access control and auditing.

»Before

Previously, Consul on Kubernetes relied on Kubernetes secrets to store sensitive data such as the ACL tokens, which are used by Consul agents to securely access the Consul API. Kubernetes secrets have several weaknesses in a zero trust security architecture:

• By default, secrets are base-64 encoded, not encrypted
• There is no lease or time-to-live with these secrets
• Kubernetes can only manage resources, such as secrets, within a cluster boundary. If you have sets of clusters, the resources across them need to be managed separately.

»After

Consul on Kubernetes can now store all Consul secrets within HashiCorp Vault — a centralized secrets management solution that closes some of the aforementioned gaps in Kubernetes secrets. Consul 1.11 began this transition by enabling storage of Consul secrets in Vault for just one deployment type: single datacenters without admin partitions. Consul 1.12 completes support for all Consul on Kubernetes deployments, including federated multi-datacenter deployments and single datacenter deployments with admin partitions enabled.

Additionally, Consul agents no longer need to store a Vault token to receive service mesh certificates from a Vault Certificate Authority (CA). Instead, Consul agents now automatically authenticate with Vault using its Kubernetes Auth method.

»Automatic Consul on Kubernetes Server TLS Certificate Rotation

Consul server and client agents leverage TLS certificates in order to secure remote procedure call (RPC) communication across the cluster. Previously, when using Vault as the CA for Consul on Kubernetes, Consul allowed automatic rotation of client TLS certificates using a feature called auto encrypt, but operators needed to manually rotate Consul server TLS certificates. With release 1.12, Consul on Kubernetes can automatically rotate TLS certificates provided by Vault for all Consul agents — now with the ability to manage the server certificates in addition to the client certificates — reducing the operational burden for issuing new certificates prior to expiry . This allows operators to reduce the time-to-live (TTL) values of their TLS certificates, thereby strengthening their security posture.

»Improved ACL Troubleshooting

In a zero trust security architecture, access to any component requires explicit authorization. Consul empowers users to apply this principle of explicit authorization across their service mesh components with two things:

1. Intentions controlling service-to-service authorization

2. ACL tokens that define permissions for accessing Consul API endpoints

For operators looking to improve their zero trust security maturity, this release makes it easier to understand ACL system behavior and define least-privilege access policies for ACL tokens. When a Consul API request is rejected due to missing ACL permissions, the Consul log now provides detailed information about why the request was rejected so operators can adjust the ACL token permissions if needed. The Consul API also indicates when results have been filtered from a successful read request due to ACL policy configuration.

Additionally, Consul now provides an easy way to display all access control policies that apply to an ACL token, including policies inherited by the token from namespace and global defaults.

»GUI: Consul Overview Page

Users who log into the Consul 1.12 UI using an ACL token with operator:read privileges will be greeted with a new high-level overview of their Consul installation, indicating places where their attention may be needed. The Overview UI Page helps quickly find answers to the following questions:

• Are any of my Consul servers down? How many servers would need to fail to affect Consul availability?
• What is the configuration of my servers, including leader and voter status, health status, and redundancy zone or read replica configuration?
• When does my enterprise license expire? How do I renew the license? What happens on expiration?

»Next Steps

Our goal with Consul is to provide an enterprise-ready, consistent control plane to discover and securely connect any application. For more information about Consul, please visit the Consul documentation. To get started with Consul 1.12, please download the binary from our release page or install the latest Helm chart that supports Consul 1.12.