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