Frequently Asked Questions (FAQ)

This FAQ section is for the license changes introduced in Vault Enterprise 1.8. We will no longer support the old license system (vault write sys/license), and autoload will be the only way to manage your license.

• Q: When will these licensing changes be released for Vault?
• Q: Will these license changes impact HCP Vault?
• Q: Do these license changes impact all Vault customers/licenses?
• Q: What is the product behavior change introduced by the licensing changes?
• Q: How will Vault behave at startup when a license expires or terminates?
• Q: What is the impact on evaluation licenses due to this change?
• Q: Are there any changes to existing methods for manual license loading ( API or CLI)?
• Q: Is there a grace period when evaluation licenses expire?
• Q: Does this affect clients?
• Q: Are the license files locked to a specific cluster?
• Q: Will a EULA check happen every time a Vault restarts?
• Q: What scenarios should a customer plan for due to these license changes?
• 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?
• 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)?
• 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?
• 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)?
• Q: Is there a limited time for support of licenses that are in storage?

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?

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.