mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-11-02 19:47:54 +00:00
First draft of Seal HA documentation (#23252)
* wip * Initial draft of Seal HA docs * nav data * Fix env var name * title * Note partially wrapped values and disabled seal participation * Update website/data/docs-nav-data.json Co-authored-by: Steven Clark <steven.clark@hashicorp.com> * correct initial upgrade limitation * Add note about shamir seals and migration * fix nav json * snapshot note * availability note * seal-backend-status * Add a couple more clarifying statements * header typo * correct initial upgrade wording * Update website/content/docs/configuration/seal/seal-ha.mdx Co-authored-by: Steven Clark <steven.clark@hashicorp.com> * Update website/content/docs/concepts/seal.mdx Co-authored-by: Steven Clark <steven.clark@hashicorp.com> --------- Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
This commit is contained in:
47
website/content/api-docs/system/seal-backend-status.mdx
Normal file
47
website/content/api-docs/system/seal-backend-status.mdx
Normal file
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
layout: api
|
||||||
|
page_title: /sys/seal-backend-status - HTTP API
|
||||||
|
description: The `/sys/seal-backend-status` endpoint is used to check the status of each seal backend.
|
||||||
|
---
|
||||||
|
|
||||||
|
# `/sys/seal-backend-status`
|
||||||
|
|
||||||
|
The `/sys/seal-backend-status` endpoint is used to display the status of
|
||||||
|
each backing seal, namely whether each backend is healthy.
|
||||||
|
|
||||||
|
## Seal Backend Status
|
||||||
|
|
||||||
|
This endpoint returns the seal status of the Vault. This is an unauthenticated
|
||||||
|
endpoint.
|
||||||
|
|
||||||
|
| Method | Path |
|
||||||
|
| :----- | :------------------------- |
|
||||||
|
| `GET` | `/sys/seal-backend-status` |
|
||||||
|
|
||||||
|
### Sample request
|
||||||
|
|
||||||
|
```shell-session
|
||||||
|
$ curl \
|
||||||
|
http://127.0.0.1:8200/v1/sys/seal-backend-status
|
||||||
|
```
|
||||||
|
|
||||||
|
### Sample response
|
||||||
|
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"healthy": false,
|
||||||
|
"unhealthy_since": "2023-09-22T08:34:11Z",
|
||||||
|
"backends": [
|
||||||
|
{
|
||||||
|
"name": "hsm",
|
||||||
|
"healthy": true
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"name": "transit",
|
||||||
|
"healthy": false,
|
||||||
|
"unhealthy_since": "2023-09-22T08:34:11Z"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
@@ -315,3 +315,76 @@ When the quorum of nodes are back up, Raft will elect a leader and the leader
|
|||||||
node that will perform the migration. The migrated information will be replicated to
|
node that will perform the migration. The migrated information will be replicated to
|
||||||
all other cluster peers and when the peers eventually become the leader,
|
all other cluster peers and when the peers eventually become the leader,
|
||||||
migration will not happen again on the peer nodes.
|
migration will not happen again on the peer nodes.
|
||||||
|
|
||||||
|
## Seal High Availability (Enterprise, Beta)
|
||||||
|
|
||||||
|
|
||||||
|
-> **Warning:** This feature is available as a Beta for evaluation and should not
|
||||||
|
be used in production deployments of Vault.
|
||||||
|
|
||||||
|
Seal High Availability (Seal HA) allows the configuration of more than one auto
|
||||||
|
seal mechanism such that Vault can tolerate the temporary loss of a seal service
|
||||||
|
or device for a time. With Seal HA Vault can also start up and unseal if one of the
|
||||||
|
configured seals is still available (though Vault will remain in a degraded mode in
|
||||||
|
this case). While seals are unavailable, seal wrapping and entropy augmentation can
|
||||||
|
still occur using the remaining seals, and values produced while a seal is down will
|
||||||
|
be re-wrapped with all the seals when all seals become healthy again.
|
||||||
|
|
||||||
|
When an operator configures an additional seal or removes a seal (one at a time)
|
||||||
|
and restarts Vault, Vault will automatically detect that it needs to re-wrap
|
||||||
|
CSPs and seal wrapped values, and will start the process. Seal re-wrapping can
|
||||||
|
be monitored via the logs or via the `sys/seal-status` endpoint. While a
|
||||||
|
re-wrap is in progress (or could not complete successfully), changes to the
|
||||||
|
seal configuration are not allowed.
|
||||||
|
|
||||||
|
In additional to high availability, Seal HA can be used to migrate between two
|
||||||
|
auto seals in a simplified manner. To migrate in this way:
|
||||||
|
|
||||||
|
1. Edit the Vault configuration, and add the new, target seal configuration.
|
||||||
|
1. Restart Vault, allowing re-wrapping to complete.
|
||||||
|
1. Edit the Vault configuration, removing the old seal configuration.
|
||||||
|
1. Restart Vault, again allowing re-wrapping to complete.
|
||||||
|
|
||||||
|
By default, Seal HA is unavailable. To try the beta, one must set an environment
|
||||||
|
variable which enables it:
|
||||||
|
|
||||||
|
`VAULT_ENABLE_SEAL_HA_BETA=true`
|
||||||
|
|
||||||
|
### Use and Configuration
|
||||||
|
|
||||||
|
Refer to the [configuration](/vault/docs/configuration/seal/seal-ha) section
|
||||||
|
for details on configuring Seal HA.
|
||||||
|
|
||||||
|
### Seal Re-Wrapping
|
||||||
|
|
||||||
|
Whenever seal configuration changes, Vault must re-wrap all CSPs and seal
|
||||||
|
wrapped values, to ensure each value has an entry encrypted by all configured
|
||||||
|
seals. Vault detects these configuration changes automatically, and triggers
|
||||||
|
a re-wrap. Re-wraps can take some time, depending on the number of
|
||||||
|
seal wrapped values. While re-wrapping is in progress, no configuration changes
|
||||||
|
to the seals can be made.
|
||||||
|
|
||||||
|
Progress of the re-wrap can be monitored using
|
||||||
|
the [`sys/sealwrap/rewrap`](/vault/api-docs/system/sealwrap-rewrap) endpoint.
|
||||||
|
|
||||||
|
### Limitations and Known Issues
|
||||||
|
|
||||||
|
As Seal HA is in beta, there are certain restrictions that may not be present in
|
||||||
|
the generally available version of the feature:
|
||||||
|
|
||||||
|
* Changing seal configurations requires a restart of Vault.
|
||||||
|
* Vault must be configured for a single seal at the time of initialization.
|
||||||
|
Extra seals can then be added.
|
||||||
|
* Upon upgrading to Vault 1.15 or higher, Vault must start with a
|
||||||
|
conventional single seal and the beta flag enabled. Afterward an additional seal
|
||||||
|
may be added.
|
||||||
|
* Seals must be added or removed one at a time.
|
||||||
|
* Only auto seals can be used in HA configurations. Shamir and auto cannot
|
||||||
|
be mixed.
|
||||||
|
* A maximum of three seals can be configured.
|
||||||
|
* As seal wrapped values must be wrapped by all configured seals, it is possible
|
||||||
|
that large values may fail to persist as the size of the entry is multiplied by
|
||||||
|
the number of seals causing it to exceed the storage entry size limit. An example
|
||||||
|
would be storing a large document in KVv2 with seal wrapping enabled.
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -15,6 +15,9 @@ include: [PKCS11 seal](/vault/docs/configuration/seal/pkcs11), [AWS KMS](/vault/
|
|||||||
Vault Enterprises's external entropy support is activated by the presence of an `entropy "seal"`
|
Vault Enterprises's external entropy support is activated by the presence of an `entropy "seal"`
|
||||||
block in Vault's configuration file.
|
block in Vault's configuration file.
|
||||||
|
|
||||||
|
~> **Note**: If using the Seal High Availability Beta, entropy will be retrieved
|
||||||
|
from seals in priority order, using bytes from the first available and online seal.
|
||||||
|
|
||||||
## Requirements
|
## Requirements
|
||||||
|
|
||||||
A valid Vault Enterprise license is required for Entropy Augmentation.
|
A valid Vault Enterprise license is required for Entropy Augmentation.
|
||||||
|
|||||||
@@ -28,7 +28,7 @@ Seal configuration can be done through the Vault configuration file using the
|
|||||||
`seal` stanza:
|
`seal` stanza:
|
||||||
|
|
||||||
```hcl
|
```hcl
|
||||||
seal [NAME] {
|
seal [TYPE] {
|
||||||
# ...
|
# ...
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|||||||
104
website/content/docs/configuration/seal/seal-ha.mdx
Normal file
104
website/content/docs/configuration/seal/seal-ha.mdx
Normal file
@@ -0,0 +1,104 @@
|
|||||||
|
---
|
||||||
|
layout: docs
|
||||||
|
page_title: Seal High Availability (Beta) - Seals - Configuration
|
||||||
|
description: |-
|
||||||
|
How to configure multiple Seals for high availability.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Seal High Availability (Beta)
|
||||||
|
|
||||||
|
<Note title="Seal HA functionality requires Vault Enterprise">
|
||||||
|
|
||||||
|
Seal High Availability requires Vault Enterprise.
|
||||||
|
|
||||||
|
</Note>
|
||||||
|
|
||||||
|
-> **Warning:** This feature is available as a Beta for evaluation and should not
|
||||||
|
be used in production deployments of Vault.
|
||||||
|
|
||||||
|
[Seal High Availability](/vault/docs/concepts/seal#seal-high-availability-enterprise-beta)
|
||||||
|
is the ability to configure more than one seal in order to have resilience against
|
||||||
|
outage of a seal service or mechanism.
|
||||||
|
|
||||||
|
Using Seal HA involves configuring extra seals in Vault's server configuration file
|
||||||
|
and restarting Vault, after having enabled the Seal HA beta feature by setting
|
||||||
|
the environment variable:
|
||||||
|
|
||||||
|
`VAULT_ENABLE_SEAL_HA_BETA=true`
|
||||||
|
|
||||||
|
Before using Seal HA, one must have upgraded to Vault 1.15 or higher and
|
||||||
|
started with the environment variable and a single seal.
|
||||||
|
|
||||||
|
## Adding and Removing Seals
|
||||||
|
|
||||||
|
Seal HA adds two new fields to the seal configuration stanza, `name`, and
|
||||||
|
`priority`:
|
||||||
|
|
||||||
|
```hcl
|
||||||
|
seal [TYPE] {
|
||||||
|
name = "seal-name"
|
||||||
|
priority = "1"
|
||||||
|
# ...
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Name is optional, and if not specified is set to the type of the seal. Names
|
||||||
|
must be unique. If using two seals of the same type name must be specified.
|
||||||
|
Internally, name is used to disambiguate seal wrapped values in some cases,
|
||||||
|
so renaming seals should be avoided if possible.
|
||||||
|
|
||||||
|
Priority is mandatory if more than one seal is specified. Priority tells Vault
|
||||||
|
the order in which to try seals during unseal (least priority first),
|
||||||
|
in the case more than one seal can unwrap a seal wrapped value, the order
|
||||||
|
in which to attempt decryption, and which order to attempt to source entropy
|
||||||
|
for entropy augmentation. This can be useful if your seals have different
|
||||||
|
performance or cost characteristics.
|
||||||
|
|
||||||
|
All configured, healthy seals are used to seal wrap values. This means that
|
||||||
|
for every write of a seal wrapped value or CSP, an encryption is requested
|
||||||
|
from every configured seal, and the results are stored in the storage entry.
|
||||||
|
When seals are unhealthy, Vault keeps track of values that could not be fully
|
||||||
|
wrapped and will re-wrap them once seals become healthy again. Disabled seals
|
||||||
|
can still be used for decryption of wrapped values, but will be avoided when
|
||||||
|
encrypting values.
|
||||||
|
|
||||||
|
When reading a CSP or seal wrapped value, Vault will try to decrypt with the
|
||||||
|
highest priority available seal, and then try other seals on failure.
|
||||||
|
|
||||||
|
To add an additional seal, simply add another seal stanza, specifying priority
|
||||||
|
and optionally name, and restart Vault.
|
||||||
|
|
||||||
|
To remove a seal, remove the corresponding seal stanza and restart. There must
|
||||||
|
be at least one seal remaining.
|
||||||
|
|
||||||
|
It is highly recommended to take a snapshot of your Vault storage before applying
|
||||||
|
any seal configuration change.
|
||||||
|
|
||||||
|
Once Vault unseals with the new seal configuration, it will be available to process
|
||||||
|
traffic even as re-wrapping proceeds.
|
||||||
|
|
||||||
|
### Safety checks
|
||||||
|
|
||||||
|
Vault will reject seal configuration changes in the following circumstances,
|
||||||
|
as a safety mechanism:
|
||||||
|
|
||||||
|
* The old seal configuration and new seal configuration do not share one seal
|
||||||
|
in common. This is necessary as there would be no seal capable of decrypting
|
||||||
|
CSPs or seal wrapped values previously written.
|
||||||
|
|
||||||
|
* Seal re-wrapping is in progress. Vault must be in a clean, fully wrapped state
|
||||||
|
on the previous configuration before attempting a configuration change.
|
||||||
|
|
||||||
|
* More than one seal is being added or removed at a time.
|
||||||
|
|
||||||
|
### Interaction with Shamir Seals
|
||||||
|
|
||||||
|
Seal HA is only supported with auto seal mechanisms. To use Seal HA when
|
||||||
|
running a Shamir seal, first use the traditional
|
||||||
|
[seal migration](/vault/docs/concepts/seal#seal-migration) mechanism to migrate to
|
||||||
|
an auto seal of your choice. Afterwards you may follow the above
|
||||||
|
instructions to add a second auto seal.
|
||||||
|
|
||||||
|
Correspondingly, to migrate back to a shamir seal, first use the above
|
||||||
|
instructions to move to a single auto seal, and use the traditional
|
||||||
|
migration method to migrate back to a Shamir seal.
|
||||||
@@ -67,6 +67,10 @@ These parameters apply to the `seal` stanza in the Vault configuration file:
|
|||||||
decryption. This may also be supplied using the `VAULT_TRANSIT_SEAL_KEY_NAME`
|
decryption. This may also be supplied using the `VAULT_TRANSIT_SEAL_KEY_NAME`
|
||||||
environment variable.
|
environment variable.
|
||||||
|
|
||||||
|
- `key_id_prefix` `(string: "")`: An optional string to add to the key id
|
||||||
|
of values wrapped by this transit seal. This can help disambiguate between
|
||||||
|
two transit seals.
|
||||||
|
|
||||||
- `mount_path` `(string: <required>)`: The mount path to the transit secret engine.
|
- `mount_path` `(string: <required>)`: The mount path to the transit secret engine.
|
||||||
This may also be supplied using the `VAULT_TRANSIT_SEAL_MOUNT_PATH` environment
|
This may also be supplied using the `VAULT_TRANSIT_SEAL_MOUNT_PATH` environment
|
||||||
variable.
|
variable.
|
||||||
|
|||||||
@@ -673,6 +673,10 @@
|
|||||||
"title": "<code>/sys/seal-status</code>",
|
"title": "<code>/sys/seal-status</code>",
|
||||||
"path": "system/seal-status"
|
"path": "system/seal-status"
|
||||||
},
|
},
|
||||||
|
{
|
||||||
|
"title": "<code>/sys/seal-backend-status</code>",
|
||||||
|
"path": "system/seal-backend-status"
|
||||||
|
},
|
||||||
{
|
{
|
||||||
"title": "<code>/sys/sealwrap/rewrap</code>",
|
"title": "<code>/sys/sealwrap/rewrap</code>",
|
||||||
"path": "system/sealwrap-rewrap"
|
"path": "system/sealwrap-rewrap"
|
||||||
|
|||||||
@@ -308,6 +308,14 @@
|
|||||||
"title": "Overview",
|
"title": "Overview",
|
||||||
"path": "configuration/seal"
|
"path": "configuration/seal"
|
||||||
},
|
},
|
||||||
|
{ "title": "High Availability (Beta)",
|
||||||
|
"badge": {
|
||||||
|
"text": "ENT",
|
||||||
|
"type": "outlined",
|
||||||
|
"color": "neutral"
|
||||||
|
},
|
||||||
|
"path": "configuration/seal/seal-ha"
|
||||||
|
},
|
||||||
{
|
{
|
||||||
"title": "AliCloud KMS",
|
"title": "AliCloud KMS",
|
||||||
"path": "configuration/seal/alicloudkms"
|
"path": "configuration/seal/alicloudkms"
|
||||||
|
|||||||
Reference in New Issue
Block a user