Improve Auto Unseal and awskms Seal documentation (#7575)
* Add further detail on Auto Unseal and awskms Seal documentation * Move Rekeying to the generic Seal docs
This commit is contained in:
parent
b496d89ef3
commit
c5b4fbd56f
|
@ -135,7 +135,7 @@ flags](/docs/commands/index.html) included on all commands.
|
||||||
providing an unseal key. The default is false.
|
providing an unseal key. The default is false.
|
||||||
|
|
||||||
- `-target` `(string: "barrier")` - Target for rekeying. "recovery" only applies
|
- `-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
|
- `-verify` `(bool: false)` - Indicate during the phase `-init` that the
|
||||||
verification process is activated for the rekey. Along with `-nonce` option
|
verification process is activated for the rekey. Along with `-nonce` option
|
||||||
|
|
|
@ -74,16 +74,16 @@ access to the master key shards.
|
||||||
|
|
||||||
## Auto Unseal
|
## Auto Unseal
|
||||||
|
|
||||||
Auto Unseal was developed to aid in reducing the operational complexity of
|
Auto Unseal was developed to aid in reducing the operational complexity of
|
||||||
keeping the master key secure. This feature delegates the responsibility 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
|
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
|
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
|
these services or devices and then stored in the storage backend allowing Vault
|
||||||
to decrypt the master key at startup and unseal automatically.
|
to decrypt the master key at startup and unseal automatically.
|
||||||
|
|
||||||
When using Auto Unseal there are certain operations in Vault that still
|
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.
|
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
|
During the initialization process, a set of Shamir keys are generated that are called
|
||||||
Recovery Keys and are used for these operations.
|
Recovery Keys and are used for these operations.
|
||||||
|
|
||||||
For a list of examples and supported providers, please see the
|
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.
|
The seal can be migrated from Shamir keys to Auto Unseal and vice versa.
|
||||||
|
|
||||||
~> **NOTE**: This is not currently supported when using replication. While
|
~> **NOTE**: This is not currently supported when using Vault Enterprise Replication.
|
||||||
the primary can be migrated without issue, the secondaries, depending on
|
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
|
which type of seal is being migrated from/to, may not work correctly. We plan
|
||||||
to support this officially in a future release.
|
to support this officially in a future release.
|
||||||
|
|
||||||
To migrate from Shamir keys to Auto Unseal, take your server cluster offline and update
|
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
|
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
|
configuration. Bring your server back up and leave the rest of the nodes offline if
|
||||||
`-migrate` flag. All unseal commands must specify the `-migrate` flag. Once the
|
using multi-server mode, then run the unseal process with the `-migrate` flag and bring
|
||||||
required threshold of unseal keys are entered, the unseal keys will be migrated to
|
the rest of the cluster online.
|
||||||
recovery keys.
|
|
||||||
|
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
|
$ 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
|
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"`
|
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
|
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
|
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
|
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
|
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.
|
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`.
|
||||||
|
|
|
@ -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
|
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.
|
or set to current under a key alias.
|
||||||
|
|
||||||
|
|
||||||
## Learn
|
## Learn
|
||||||
|
|
||||||
Refer to the [Auto-unseal using AWS KMS](https://learn.hashicorp.com/vault/operations/ops-autounseal-aws-kms)
|
Refer to the [Auto-unseal using AWS KMS](https://learn.hashicorp.com/vault/operations/ops-autounseal-aws-kms)
|
||||||
|
|
Loading…
Reference in New Issue