Vault Seal and Unseal: Manual and Auto-Unseal Config (2026)

Vault’s auto-unseal is a brilliant piece of engineering that often gets misunderstood because it’s not about preventing a seal, but about automating the process of breaking that seal.

Let’s see it in action. Imagine Vault is running, sealed. You’d typically run vault operator unseal and paste in a shard. But with auto-unseal, Vault is already talking to a KMS (Key Management Service) provider.

# What Vault is trying to do behind the scenes (simplified)
# This is NOT a command you run directly, but illustrates the flow.
VAULT_ADDR="http://127.0.0.1:8200" vault write sys/unseal \
    key=<unseal_key_shard_1> \
    key=<unseal_key_shard_2> \
    key=<unseal_key_shard_3>

# With auto-unseal, the KMS provider handles generating/retrieving the unseal key
# and Vault receives it.

The core problem auto-unseal solves is operational burden and risk. Manually unsealing Vault requires multiple people to coordinate, often with physical access to key shards or secure storage. This process is slow, error-prone, and introduces a human bottleneck. Auto-unseal delegates the secure storage and retrieval of the master encryption key to a dedicated, hardened service like AWS KMS, Azure Key Vault, or Google Cloud KMS.

Here’s how it works internally: When Vault is initialized, it generates a master encryption key (MEK). This MEK is then encrypted by a Key Encryption Key (KEK) managed by your chosen KMS provider. Vault stores this encrypted MEK. For Vault to decrypt secrets, it needs the MEK. To get the MEK, Vault calls out to the KMS provider, authenticating itself, and requests the decryption of the encrypted MEK using the KEK. If successful, the KMS returns the decrypted MEK, and Vault can then use it to decrypt its data.

The critical levers you control are in Vault’s configuration:

api_addr: This must be reachable by the KMS provider if it’s a cloud KMS. For example:
```
api_addr = "http://192.168.1.100:8200" # Vault's public IP and port
```
This tells Vault where it can be reached, which is important for certain KMS providers that might need to callback or for Vault to construct correct URLs for KMS interactions.
KMS Configuration: This is the heart of auto-unseal. The syntax varies by provider.
- AWS KMS:
```
storage "raft" {
  path    = "/vault/data"
  node_id = "node1"
}

seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "alias/my-vault-key" # Or the full ARN
}
```
  Here, region specifies where your KMS key resides, and kms_key_id points to the specific Key Encryption Key. Vault uses these to authenticate with AWS IAM and perform the cryptographic operations.
- Azure Key Vault:
```
storage "file" {
  path = "/vault/data"
}

seal "azurekeyvault" {
  key_name         = "my-vault-key"
  key_vault_name   = "my-kv-vault"
  use_managed_identity = true
}
```
  key_name and key_vault_name identify the KEK in Azure. use_managed_identity is crucial for Azure VMs or other services to authenticate to Key Vault without explicit credentials.
- Google Cloud KMS:
```
storage "file" {
  path = "/vault/data"
}

seal "gcpckms" {
  project = "my-gcp-project"
  region  = "us-central1"
  key_ring = "my-vault-keyring"
  crypto_key = "my-vault-crypto-key"
}
```
  These parameters specify the GCP project, region, and the specific KMS key resource. Authentication typically relies on the service account running Vault.

When Vault starts, it checks its seal configuration. If it finds an auto-unseal configuration, it attempts to contact the specified KMS provider. It uses its configured credentials (IAM roles, managed identities, service accounts) to authenticate. It then requests the KMS to decrypt the encrypted master encryption key it has stored. If the KMS operation is successful, Vault receives the decrypted master key and proceeds to start in an unsealed state. If it fails, Vault remains sealed.

The most surprising aspect for many is how Vault manages its own encryption key. It doesn’t store the unseal key itself; instead, it stores an encrypted version of its master encryption key. The "key shard" concept you might be familiar with from manual unsealing is abstracted away. The KMS provider is the secure vault for the actual unseal mechanism. This means the KMS provider must be highly available and correctly configured, as it’s a single point of failure for Vault’s ability to start.

Once auto-unseal is configured and working, the next step is often to explore advanced storage backends like Raft for HA setups, or to integrate Vault with other systems for dynamic secrets.

More Deep Dives in Vault