The Master Key Problem
If Vault encrypts everything on disk, it needs an encryption key to do that. Call this the Encryption Key. But where do you store that key safely? If you store it right next to the encrypted data on disk, it is like leaving the house key under the doormat — the first place an attacker looks.
Vault solves this with a concept called Sealing.
Sealed vs. Unsealed State
When a Vault server starts up, it is in a Sealed state. It knows where the encrypted data lives on disk, but it cannot read any of it because the Encryption Key has not been loaded into memory. A sealed Vault is essentially a locked safe with no combination entered yet — it is running, but completely inaccessible.
To move to an Unsealed state, Vault needs its Master Key reconstructed in memory. Once unsealed, Vault can decrypt data and serve requests normally. If the server reboots, Vault returns to Sealed state and must be manually unsealed again. This is a deliberate security feature — an attacker who reboots your server cannot access secrets without the unseal keys.
Shamir's Secret Sharing
Vault does not give the Master Key to a single person. That would create a single point of failure — if that person is unavailable, compromised, or malicious, the entire system is at risk.
Instead, Vault uses a mathematical algorithm called Shamir's Secret Sharing to split the Master Key into multiple key shares (think of it like splitting a treasure map into pieces). You configure two parameters:
- Total shares (N): How many pieces to create (e.g., 5)
- Threshold (K): How many pieces are required to reconstruct the key (e.g., 3)
You distribute one share each to the CTO, the Lead DevOps Engineer, the CISO, the Security Lead, and the Head of Infrastructure. No single person can unseal Vault alone. When the server restarts, at least 3 of the 5 holders must come together, each entering their share via the Vault CLI or UI. Vault mathematically reconstructs the Master Key in memory, unseals itself, and the shares are discarded from memory — they are never stored together. Initializing Vault this way (vault operator init with a key-shares and key-threshold count) prints each unseal key exactly once, and unsealing requires the threshold number of holders to each submit their key in turn.
Auto-Unseal: The Operational Reality
Requiring 3 humans to be available every time a Vault server restarts is operationally painful in a cloud environment where servers may restart frequently. Vault supports Auto-Unseal using a cloud KMS (Key Management Service) — AWS KMS, GCP Cloud KMS, or Azure Key Vault. Instead of human key holders, Vault automatically calls the cloud KMS to decrypt its Master Key on startup. The security model shifts: you now trust the cloud KMS and its IAM controls rather than human key holders. This is the standard approach for production cloud deployments.