HashiConf 2024 Now streaming live from Boston! Attend for free
Vault
Vault Home

You are viewing documentation for version v1.10.x. View latest version.

License FAQ

This FAQ section is for the license changes introduced in Vault Enterprise 1.8.

Q: When will these licensing changes be released for Vault?

The licensing and end-user license agreement (EULA) changes will be available with Vault 1.8-RC1 on June 16, 2021. Vault 1.8 is targeted to release on July 28, 2021.

Q: Will these license changes impact HCP Vault?

No, these changes will not impact HCP Vault.

Q: Do these license changes impact all Vault customers/licenses?

Customer/licensesImpacted?
ENT binaries (evaluation or non-evaluation downloaded from releases.hashicorp.com)Yes
Open-Source (OSS)No
Baked-in license binaries (pro/premium)No

Q: What is the product behavior change introduced by the licensing changes?

With Vault 1.8, a valid license is required on-disk (auto-loading) or in-storage for Vault to boot up successfully.

  • Existing clusters upgrading to Vault 1.8 or later will not be affected. Customers may continue to use an in-storage license for their existing clusters until they decide to move to auto-loading. Please see the question below: Is there a limited time for support of licenses that are in storage?

  • When deploying Vault 1.8 or later clusters, please ensure a valid license exists on-disk (auto-loading).

Q: How will Vault behave at startup when a license expires or terminates?

When a license expires, Vault continues to function until the license terminates. This behavior exists today and remains unchanged in Vault 1.8. The grace period, defined as the time between license expiration and license termination, is 1 day for evaluation licenses (as of 1.8), and ten years for non-evaluation licenses. Customers must install a valid license before the grace period expires. This license can be autoloaded or loaded into storage using existing methods (/sys/license) depending on the applicable scenarios as described above. When license terminates (upon grace period expiry), Vault will seal itself and customers will need a valid license in order to successfully bring-up Vault. If a valid license was not installed after license expiry, customers will need to install one, and this license will need to be auto-loaded.

Q: What is the impact on evaluation licenses due to this change?

The 6-hour trial period for Enterprise binaries allows these particular binaries to run without a license file and will be removed as of Vault 1.8 and later. This change means that any clusters deployed with Vault 1.8 or later ENT binaries must have a valid license, and the license must be on the disk (auto-loading).

Q: Are there any changes to existing methods for manual license loading ( API or CLI)?

There are no significant changes to the API or CLI license loading with Vault 1.8. However, the /sys/license endpoint is slated for deprecation in a future release. Please see the question: Is there a limited time for support of licenses that are in storage?

Q: Is there a grace period when evaluation licenses expire?

Evaluation licenses have a 1-day grace period. The grace period is the time until the license expires. Upon expiration, Vault will seal and will require a valid license to unseal and function properly.

Q: Does this affect clients?

No, there is no impact to the Vault Agent.

Q: Are the license files locked to a specific cluster?

The changes to licenses apply to all nodes in a cluster. The license files are not locked to a cluster, but are independently applied to the appropriate clusters.

Q: Will a EULA check happen every time a Vault restarts?

Yes, starting with Vault 1.8, ENT binaries will be subjected to a EULA check. The release of Vault 1.8 introduces the EULA check for evaluation licenses (non-evaluation licenses are evaluated with a EULA check during contractual agreement) . Although the agreement to a EULA occurs only once (when the user receives their license), Vault will check for the presence of a valid license every time a node is restarted.

When a customer upgrades existing clusters to Vault 1.8 or later, a valid license must exist to upgrade successfully. This valid license must be in storage or on-disk (auto-loaded). Please see the below question: Is there a limited time for support of licenses that are in storage?

Also, when customers deploy new clusters to Vault 1.8 or later, a valid license must exist to upgrade successfully. This valid license must be on-disk (auto-loaded).

Q: What scenarios should a customer plan for due to these license changes?

  • New Cluster Deployment: When a customer deploys new clusters to Vault 1.8 or later, a valid license must exist to successfully deploy. This valid license must be on-disk (auto-loaded).

  • Eventual Migration: Since in-storage licenses will not be supported forever, migrating to auto-loaded licenses will be required. Please see the below question: Is there a limited time for support of licenses that are in storage?

Q: What is the migration path for customers who want to migrate from their existing license-as-applied-via-the-CLI flow to the license on disk flow?

If a Vault 1.7 cluster is upgraded to Vault 1.8 or later and still has a stored license, the operator must migrate using an auto-loaded license.

  1. Use the new command vault license get -signed to retrieve the license from the storage in their running cluster.
  2. Put the license on disk, configure auto-loading (new license_path config option, OR new environment variable VAULT_LICENSE_PATH OR new environment variable VAULT_LICENSE containing the actual license itself).
  3. Restart the Vault node.
  4. A warning will explain that the license is in storage and using auto-loading.
  5. Use the new command vault delete /sys/license to fully transition to auto-loading.

Q: What is the migration path for customers who wish to migrate from their existing perpetually licensed binaries to the license on disk flow (auto-loading)?

A Vault customer who is currently using S3 unlocked binaries, upgrading their clusters to Vault 1.8 or later, and wishes to move to auto-loading, will need a valid enterprise binary version 1.8 or later and a valid license. The steps are the same as in the above question: What is the migration path for customers who want to migrate from their existing license-as-applied-via-the-CLI flow to the license on disk flow? starting at Step 2.

Q: What is the migration path for customers who want to migrate from their existing perpetually licensed binaries to the current license on storage flow?

A Vault customer currently using S3 unlocked binaries is upgrading their clusters to a pre-Vault 1.8 version, the customer must retrieve the corresponding enterprise binary and a valid license to load the license in storage (/sys/license). Please see the below question: Is there a limited time for support of licenses that are in storage?

Q: What is the path for customers who want to downgrade/rollback from Vault 1.8 or later (auto-loading) to a pre- Vault 1.8 (license in storage)?

The downgrade procedure remains the same for Vault customers who are currently on Vault 1.8 or later, have a license installed via auto-loading, and would like to downgrade their cluster to a pre-1.8 version that does not have auto-loading support and only supports license in storage. Please refer to the upgrade procedures that remind the customers that they must take a snapshot before the upgrade. Customers will need to restore their version from the snapshot, apply the pre-1.8 enterprise binary version they wish to roll back, and bring up the clusters.

Q: Is there a limited time for support of licenses that are in storage?

The support of licenses installed by alternative means often leads to difficulties providing the appropriate support. To provide the support expected by our customers, we plan to scale support for licenses in storage for Vault. With this plan, Vault customers have up to a 1-year migration period, or until the release of Vault 1.11, to migrate their licenses from in-storage to auto-loading. Starting with Vault 1.11, licensing endpoints that are put in storage will be removed, and Vault will no longer check for valid licenses in storage. This change requires that all customers have auto-loaded licenses to upgrade to 1.11(+) successfully.

Q: What are the steps to upgrade from one autoloaded license to another autoloaded license?

Follow these steps to migrate from one autoloaded license to another autoloaded license.

  1. Use the vault license inspect command to compare the new license against the output of the vault license get command. This is to ensure that you have the correct license.
  2. Backup the old license file in a safe location.
  3. Replace the old license file on each Vault server with the new one.
  4. Invoke the reload command on each individual Vault server, starting with the standbys and doing the leader last. Invoking in this manner reduces possible disruptions if something was performed incorrectly with the above steps. You can either use the reload command or send a SIGHUP.
  5. On each node, ensure that the new license is in use by using the vault license get command and/or checking the logs.

ADP Licensing

This FAQ section is for the Advanced Data Protection (ADP) license changes introduced in Vault Enterprise 1.8.

Q: What are the Vault ADP module licensing changes introduced in 1.8?

As of Vault Enterprise 1.8, the functionality formerly sold as the Vault ADP module is now separated between two new modules:

ADP-KM includes:

ADP-Transform includes:

Q: How can the new ADP modules be purchased and what features are customer entitled to as part of that purchase?

ADP-KM includes:

  • This is the first Vault Enterprise module that can be purchased standalone. This means it can be purchased without the purchase of a Vault Enterprise Standard license.
  • ADP-KM still requires a Vault Enterprise binary. The Vault Enterprise Standard license is automatically included with the ADP-KM module, but customers are contractually prohibited from using any features besides those in Vault OSS and ADP-KM (KMSE and KMIP).

ADP-Transform includes:

  • This module cannot be purchased as a standalone. It requires a Vault Enterprise binary, and customers must purchase the base Vault Enterprise Standard license (at least) to use the corresponding Enterprise features.
  • The ADP-Transform SKU can be applied as an add-on. This workflow is similar to the consolidated ADP SKU.

Q: What is the impact to customers based on these ADP module licensing changes?

Customers need to be aware of the following as a result of these changes:

  • New customers may choose to purchase either or both of these modules. The old (consolidated) module is not available to them as an option.
  • Existing customers may continue with the consolidated Vault ADP module uninterrupted. They will only be converted to one or both new ADP modules the next time they make a change to their licensing details (i.e. contract change).