Merge branch 'master' into ui-generated-items

CHANGELOG.md

@@ -32,6 +32,9 @@ IMPROVEMENTS:
  * auth/jwt: Bound claims may now contain boolean values [JWT-73]
  * auth/jwt: CLI logins can now open the browser when running in WSL [JWT-77]
  * core: Exit ScanView if context has been cancelled [GH-7419]
+ * core: re-encrypt barrier and recovery keys if the unseal key is updated
+   [GH-7493]
+ * core (enterprise): Add background seal re-wrap
  * core/metrics: Add config parameter to allow unauthenticated sys/metrics 
    access. [GH-7550]  
  * replication (enterprise): Write-Ahead-Log entries will not duplicate the
@@ -84,6 +87,8 @@ BUG FIXES:
 
  * agent: Fix handling of gzipped responses [GH-7470]
  * cli: Fix panic when pgp keys list is empty [GH-7546]
+ * core: add hook for initializing seals for migration [GH-7666]
+ * core (enterprise): Fix seal migration in enterprise
  * identity: Add required field `response_types_supported` to identity token
    `.well-known/openid-configuration` response [GH-7533]
  * secrets/database: Fix bug in combined DB secrets engine that can result in

website/source/docs/commands/operator/rekey.html.md

@@ -135,7 +135,7 @@ flags](/docs/commands/index.html) included on all commands.
   providing an unseal key. The default is false.
 
 - `-target` `(string: "barrier")` - Target for rekeying. "recovery" only applies
-  when HSM support is enabled.
+  when HSM support is enabled or using [Auto Unseal](/docs/concepts/seal.html#auto-unseal).
 
 - `-verify` `(bool: false)` - Indicate during the phase `-init` that the
   verification process is activated for the rekey. Along with `-nonce` option

website/source/docs/concepts/seal.html.md

@@ -74,16 +74,16 @@ access to the master key shards.
 
 ## Auto Unseal
 
-Auto Unseal was developed to aid in reducing the operational complexity of 
-keeping the master key secure. This feature delegates the responsibility of 
-securing the master key from users to a trusted device or service. Instead of 
-only constructing the key in memory, the master key is encrypted with one of 
-these services or devices and then stored in the storage backend allowing Vault 
-to decrypt the master key at startup and unseal automatically. 
+Auto Unseal was developed to aid in reducing the operational complexity of
+keeping the master key secure. This feature delegates the responsibility of
+securing the master key from users to a trusted device or service. Instead of
+only constructing the key in memory, the master key is encrypted with one of
+these services or devices and then stored in the storage backend allowing Vault
+to decrypt the master key at startup and unseal automatically.
 
 When using Auto Unseal there are certain operations in Vault that still
-require a quorum of users to perform an operation such as generating a root token. 
-During the initialization process, a set of Shamir keys are generated that are called 
+require a quorum of users to perform an operation such as generating a root token.
+During the initialization process, a set of Shamir keys are generated that are called
 Recovery Keys and are used for these operations.
 
 For a list of examples and supported providers, please see the
@@ -93,17 +93,19 @@ For a list of examples and supported providers, please see the
 
 The seal can be migrated from Shamir keys to Auto Unseal and vice versa.
 
-  ~> **NOTE**: This is not currently supported when using replication. While
-  the primary can be migrated without issue, the secondaries, depending on
+  ~> **NOTE**: This is not currently supported when using Vault Enterprise Replication.
+  While the primary can be migrated without issue, the secondaries, depending on
   which type of seal is being migrated from/to, may not work correctly. We plan
   to support this officially in a future release.
 
 To migrate from Shamir keys to Auto Unseal, take your server cluster offline and update
 the [seal configuration](/docs/configuration/seal/index.html) with the appropriate seal
-configuration.  When you bring your server back up, run the unseal process with the
-`-migrate` flag.  All unseal commands must specify the `-migrate` flag.  Once the
-required threshold of unseal keys are entered, the unseal keys will be migrated to 
-recovery keys.
+configuration. Bring your server back up and leave the rest of the nodes offline if
+using multi-server mode, then run the unseal process with the `-migrate` flag and bring
+the rest of the cluster online.
+
+All unseal commands must specify the `-migrate` flag. Once the required threshold of
+unseal keys are entered, unseal keys will be migrated to recovery keys.
 
 ```
 $ vault operator unseal -migrate
@@ -112,7 +114,15 @@ $ vault operator unseal -migrate
 To migrate from Auto Unseal to Shamir keys, take your server cluster offline and update
 the [seal configuration](/docs/configuration/seal/index.html) and add `disabled = "true"`
 to the seal block.  This allows the migration to use this information to decrypt the key
-but will not unseal Vault.  When you bring your server back up, run the unseal process 
-with the `-migrate` flag and use the Recovery Keys to perform the migration. All unseal 
+but will not unseal Vault.  When you bring your server back up, run the unseal process
+with the `-migrate` flag and use the Recovery Keys to perform the migration. All unseal
 commands must specify the `-migrate` flag. Once the required threshold of recovery keys
 are entered, the recovery keys will be migrated to be used as unseal keys.
+
+## Recovery Key Rekeying
+
+During Auto Seal initialization process, a set of Shamir keys called Recovery Keys are
+generated which are used for operations that still require a quorum of users.
+
+Recovery Keys can be rekeyed to change the number of shares or thresholds. When using the
+Vault CLI, this is performed by using the `-target=recovery` flag to `vault operator rekey`.

website/source/docs/configuration/seal/awskms.html.md

@@ -115,7 +115,6 @@ encrypted data.  Old keys must not be disabled or deleted and are used to decryp
 Any new or updated data will be encrypted with the current key defined in the seal configuration
 or set to current under a key alias.
 
-
 ## Learn
 
 Refer to the [Auto-unseal using AWS KMS](https://learn.hashicorp.com/vault/operations/ops-autounseal-aws-kms)