Concept and mechanism
Vault encrypts data before storage. A sealed node can reach storage without being able to decrypt data: unsealing makes the required key chain available. With Shamir, each node needs the share threshold; partial progress on several nodes does not form one global threshold. Root tokens and unsealing are different functions. Auto-unseal delegates protection to a mechanism such as KMS, creating an operational dependency. Recovery keys authorize certain operations but do not replace the seal mechanism’s ability to decrypt the root key. A snapshot also does not recreate a permanently lost key. Include connectivity, authorization, and seal-material protection in recovery planning.
Guided application
HA within one cluster and replication between clusters address different failures. In normal HA, an active node serves operations while standbys forward or redirect; do not assume write scaling by adding nodes. In Raft, five stable voters require three for quorum plus communication between them. Performance and DR replication require an appropriate edition or service and have different contracts: performance secondaries maintain their own tokens and leases; DR preserves that state and does not serve normal requests before promotion. With HCP Vault Dedicated, the provider operates the platform while the customer retains policies, integration, usage, and application validation after recovery. For CLI clients, configure an approved endpoint and CA; permanently disabling TLS is not a solution to an incorrect chain.
KMS unreachable after a network change: recovery keys and snapshots do not remove that dependency.
Common pitfalls
Root as unseal; recovery as KMS key; standby as DR; managed as no responsibility.
Related topics: Authentication and identity · Policies, paths, and capabilities · Tokens, leases, and renewal
Exercise recovery dependencies and the application as well as cluster startup.
Reference: Seal, unseal and recovery keys · Vault Associate (003); product version tested: Vault 1.19