luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

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:
Alberto Alvarez 2019-10-16 08:25:41 -07:00 committed by Chris Hoffman
parent b496d89ef3
commit c5b4fbd56f
3 changed files with 27 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/source/docs/commands/operator/rekey.html.md
View File

@ -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

42
website/source/docs/concepts/seal.html.md
View File

@ -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`.

1
website/source/docs/configuration/seal/awskms.html.md
View File

@ -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)