If you install and configure HashiCorp Vault without HSM Auto Unseal, Vault employs Shamir’s Secret Sharing Algorithm (en.wikipedia.org/wiki/Shamir%27s_secret_sharing) to prevent one person from having complete access to the system. This process divides a secret into a subset of parts so that you need a subset of those parts to reconstruct the original secret. Vault heavily uses this algorithm as part of the unsealing process (developer.hashicorp.com/vault/docs/concepts/seal). When you initialize a Vault server, Vault generates a root key (previously known as master key) and splits this root key into a series of key shares following Shamir’s Secret Sharing Algorithm. The root key decrypts the underlying encryption key. Vault uses the encryption key to encrypt data at rest in a storage backend such as Integrated Storage (developer.hashicorp.com/vault/tutorials/raft/raft-storage). Distribute each of these key shares to trusted parties in the organization. These parties must then come together to unseal the Vault by entering their key share. In some cases, such as the following ones, you might want to re-generate the root key and its key shares:Documentation Index
Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
Use this file to discover all available pages before exploring further.
- Someone joins or leaves the organization.
- Security wants to change the number of shares or the threshold.
- Compliance mandates that the keys be rotated at regular intervals.
Rekey Vault
To rekey the Vault with HSM Auto Unseal configured, use the vault operator rekey command with the -target=recovery flag. This command generates a new set of recovery keys. It does not generate a new root key on the Vectera Plus. The process can optionally modify the total number of recovery key shares or the recovery key threshold required. Note that recovery keys cannot decrypt the root key; they are purely for authorization purposes.Run the following command to initialize the rekeying operation, modifying the key shares and key threshold values:
Shell
This command generates a nonce value and starts the rekeying process, as shown in the following example output. All other unseal keys must also provide this nonce value. This nonce value is not a secret, so it is safe to distribute over insecure channels like chat or email.
Shell
Each key holder runs the following command, specifying their unique recovery key in the last field instead of this example recovery key ( Example output:
8iJCZkAqmFcIh7KyTQcyH7p/dPVFOUsEnSq/p5E1g9KX):Shell
Shell
Rotate the encryption key
Unlike rekeying the Vault, rotating the Vault encryption key does not require a quorum of recovery keys. Anyone with the proper permissions in Vault can perform the encryption key rotation. You can rotate keys automatically or manually.With Vault 1.7 and later, Vault automatically rotates the backend encryption key before reaching 232 encryption operations, in adherence with NIST SP800-32D guidelines.
Adjust automatic key rotation
Perform the following steps to adjust automatic key rotation:Run the following command to view the current automatic rotation policy:Example output:
Shell
This returns the current status and configuration of automatic encryption key rotation, as shown in the following output example.
Shell
Run the following command to configure a time interval for automatic key rotation:Example output:
Shell
Shell
Perform manual key rotation
Run the following command to trigger a key rotation:Shell
Shell
This adds a new key to the keyring. This new key encrypts all new values written to the storage backend.