There was inconsistency in the capitalization of auto unseal in this doc. The initial heading had it right. It shouldn't be capitalized according to the documentation style guidance for feature capitalization. Also, high availability doesn't need to be capitalized.
Change warning to tag syntax so it's clear what should be part of the aside
---------
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Added a note about seal-rewrap in the steps to perform seal migration post Vault 1.5.1
---------
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* Do not refresh seal-wrapped values when there are unhealthy seals.
Modify Access.IsUpToDate() to consider entries as being up-to-date when one or
more encryption wrappers fail to encrypt the test value, since re-wrapping the
value would result in the loss of the ciphertext for the unhealthy wrappers.
In addition, make Access.IsUpToDate() return true is the key set ID has not been
populated and the caller has not forced key ID refresh.
Make Access.Encrypt() return an error for any encryption wrapper that is skipped
due to being unhealthy.
* Update Seal HA documentation.
Mention that the barrier key and the recovery keys cannot be rotated while there
are unhealthy seals.
Document environment variable VAULT_SEAL_REWRAP_SAFETY.
* Seal HA documentation updates
* anchor
* rel link
* remove beta
* try again on internal link
* still trying to get this internal redirect to work
* try without path
* 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>
* Add a stronger warning about the usage of recovery keys
* Update website/content/docs/concepts/seal.mdx
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
* Keep the mitigation text in the warning box
---------
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
This article seems to use the terms "shares" and "shards" interchangeably to describe the parts in which the secret is split under SSS.
While both seem to be correct, sticking to one term would save a newbie reader (like myself) the confusion.
Since the Wikipedia article that's linked in this article only mentions "shares" and the CLI flags (for recovery keys) also use `-shares`, I opted for that.
* Update seal.mdx
The following sentence does not read easily:
"Take down the old active node, update its configuration of the old active node to use the new seal blocks (completely unaware of the old seal type) and bring it back up."
I have changed this to the sentence below, which I believe reads better.
Take down the old active node, update its configuration to use the new seal blocks (completely unaware of the old seal type) and bring it back up.
* Update website/content/docs/concepts/seal.mdx
* trigger ci
Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
Co-authored-by: taoism4504 <loann@hashicorp.com>
