Vault 1.14 brings ACME for PKI, AWS roles, and more improvements

HashiCorp is pleased to announce the general availability of Vault 1.14. HashiCorp Vault provides secrets management, data encryption, identity management, and other workflow improvements for applications on any infrastructure.

Vault 1.14 focuses on Vault’s core secrets workflows as well as team workflows, integrations, and visibility. Key additions in this release include:

• Vault Secrets Operator (GA)
• ACME PKI
• OpenLDAP secrets engine
• Multi-issuer functionality for the Vault Terraform provider
• Vault Agent decoupling
• Replication improvements
• Licensing utilization improvements
• User experience improvements for sidebars, banners, and PKI
• Environmental variable injection with Vault Agent
• AWS static secrets roles
• MongoDB Atlas secrets engine X.509 auth support

Let’s take a closer look at each of these updates:

»Vault Secrets Operator (GA)

The Vault Secrets Operator connects Vault secrets directly into native Kubernetes secrets, freeing application developers to focus on application code while returning control over secrets to your security and operations teams.

The Vault Secrets Operator insulates the application from any complexity of interacting with Vault. The application consumes these secrets as native Kubernetes Secrets and the Vault Secrets Operator maintains them within Vault as the source of truth.

As secrets change in Vault, the Vault Secrets Operator can be configured to roll the affected pods to pick up the new secrets without having to modify applications. This centralizes control and simplifies the transition from static to dynamic secrets. The Vault Secrets Operator also reduces footprint and compute load by running at the cluster level in Kubernetes.

This approach presents a native experience for application developers and platform operations team. It returns control over secrets back to the platform security team, helping them manage secrets, update policies, control access in a consistent way, and report on access events through central auditing.

»PKI ACME support

Automated Certificate Management Environment (ACME) is a protocol that automates the creation, issuance, and renewal of certificates without human interaction. Prior to Vault 1.14, organizations interested in ACME for their PKI could not leverage Vault or would be dependent on manual processes, Vault APIs, or other alternatives to automate certificate lifecycle management.

Vault 1.14 introduces ACME to help customers automate certificate lifecycle management using industry-standard tooling for private PKI needs, eliminating dependency on manual processes or alternate products. Standard ACME clients, such as Certbot, CNCF's Kubernetes cert-manager, can automate certificate requests from Vault without needing to know Vault APIs or auth mechanisms.

»OpenLDAP secrets engine

Early versions of Vault added support for the Active Directory (AD) secrets engine and management of service accounts beyond AD, leading to the development and release of the OpenLDAP secrets engine today in Vault 1.14.

In past versions of Vault, support for AD and LDAP were in independent workstreams. Vault 1.14 merges features from the AD secrets engine into the OpenLDAP secrets engine. This enhancement reduces the need for ongoing maintenance of existing features on both engines and eliminates separate mounts by users who want to use non-overlapping features from both engines.

The AD secrets engine will be deprecated, and it will be updated only for security-related fixes until its removal. Going forward, new features will be added to OpenLDAP secrets engine. The transition of deprecation to removal will occur over an extended period of time, longer than Vault's 24 month schedule, to allow more time for users to migrate to the OpenLDAP secrets engine.

»Multi-issuer functionality added to Vault Terraform provider

Multi-issuer functionality was introduced to the PKI secrets engine in Vault 1.11. While the long term sustainability and feature parity of the Terraform Vault provider has been improving, it is still a few versions behind Vault on some key features, including multi-issuer functionality. In some use cases this has led to users being unable to configure multi-issuers using the Vault provider. Vault 1.14 extends multi-issuer functionality so customers can take advantage of automation provided by the Terraform Vault provider for Vault PKI.

»Vault Agent decoupling

The Vault Agent supports two primary use cases: template and proxy. Templating involves using Vault Agent to abstract the Vault API calls from an application requiring secrets so the application can read the secrets from a file generated by Vault Agent.

The Vault Agent also supports another use case, called API proxying. This use case supports requests that will ultimately be forwarded to Vault itself. Unlike the templating use case, there is no API abstraction, and clients must know how to use Vault’s APIs. We do, however, offer caching capabilities (currently limited to a small subset of requests) to reduce the load on Vault when requests are sent through the proxy this way.

Vault 1.14 decouples these two modes so customers can run Vault Agent for templating or Vault Proxy. We plan to deprecate support for running in both modes by Vault 1.17. New features, such as static secret caching, are scheduled to be added to Vault Proxy in future releases.

»Replication improvements

Vault 1.14 resolves a race condition that could result in tokens being created on a previous disaster recovery (DR) primary. This was due to the sscGenCounter key being reverted by DR replication. To learn more, please refer to the Vault 1.14 release notes.

»Licensing utilization improvements

Vault 1.14 includes features to improve clarity for license utilization. To learn more about these features and potential impacts to customers, please see our license utilization reporting reporting FAQ.

»User experience improvements

Vault 1.14 introduces a number of user experience upgrades:

Sidebar-based navigation: Vault 1.14 implements a new sidebar-based navigation system in Vault’s GUI using the unified HashiCorp Design System to reorganize the navigation. This feature streamlines HCP Vault and Vault GUIs, removes some UX challenges, clarifies system status, and makes features more discoverable.

Dismissable banners: We’ve found that customers can sometimes be confused when they see banners in Vault’s GUI, which can lead to unnecessary support requests regarding the licensing banner. VaultVault 1.14 allows users to disable banners.

PKI user experience: Customers using the Vault PKI UI had to perform numerous manual steps for managing X.509 certificates and had no support for non-disruptive PKI root certificate rotation. Vault 1.14 improves the PKI workflow to make it easier to manage certificates. It includes an intuitive configuration and reasonable defaults for workflows, metadata, issuer info, cross signing, and multi-issuers.

»Environmental variable injection with Vault Agent

In recent years, the industry has been moving in the direction of 12-factor applications, which consume their configurations from environmental variables. A typical 12-factor service starts by reading all environmental variables and using them to initialize connections to various databases, message queues, and other services. For 12-factor applications, secrets (such as database credentials, certificates, and API keys) can be seen as special configuration entries loaded through environment variables.

Vault 1.14 introduces easy-to-use, first-class support for environmental variable injection with Vault Agent. This support includes three elements:

1. The Vault Agent provides secrets as environmental variables to a command
2. A Helper command generates the agent configuration
3. An agent can restart the child process with static or dynamic secret updates

»AWS static secret roles

Historically, AWS secrets engine has not managed static users and has created new users every time credentials are read from Vault, making user management difficult with respect to hard limits and time-to-live (TTL) considerations. Vault 1.14 includes support for static users via the AWS secrets engine. Support for static roles includes the rotation frequency at which Vault must change the associated IAM user’s access keys.

»Upgrade details

This release also includes more new features, workflow enhancements, general improvements, and bug fixes. All of these updates can be found in the Vault 1.14 changelog. Please visit the Vault release highlights page for step-by-step tutorials demonstrating the new features.

As always, we recommend upgrading and testing new releases in an isolated environment. If you experience any issues, please report them on the Vault GitHub issue tracker or post to the Vault discussion forum. As a reminder, if you believe you have found a security issue in Vault, please responsibly disclose it by emailing security@hashicorp.com — do not use the public issue tracker. For more information, please consult our security policy and our PGP key.

For more information about Vault Enterprise, visit hashicorp.com/products/vault.