Vault internals: storage, seal, and replication

Raft, the seal/unseal barrier, auto-unseal, and HA/DR/performance replication.

You cannot operate a secrets platform you do not understand internally, so this lesson opens the box. We use HashiCorp Vault as the reference architecture because its model — a storage backend sealed behind an encryption barrier, unsealed with a master key, replicated for HA and DR — is the same shape every serious secrets system uses. Grasp the seal barrier and the replication modes and you can reason about failure, recovery, and trust boundaries in any of them.

The encryption barrier and the seal

Everything Vault persists is written through an encryption barrier: data is encrypted with a barrier key before it ever touches storage, so the storage backend (Raft, Consul, S3) only ever sees ciphertext. The barrier key itself is encrypted by the master key, and the master key is what "unsealing" reconstructs. When Vault starts it is sealed — it has the ciphertext but not the master key, so it can decrypt nothing and serves no requests. Unsealing provides the master key, Vault decrypts the barrier key into memory, and only then can it serve secrets.

Shamir vs auto-unseal

By default the master key is split with Shamir’s Secret Sharing into key shares handed to different people; a threshold of them (say 3 of 5) must be provided to unseal. That is excellent for a break-glass root ceremony but miserable operationally — every restart needs humans. Auto-unseal delegates the master-key wrap to a cloud KMS or HSM: Vault asks the KMS to decrypt its stored master key at startup and unseals itself. You trade a manual ceremony for a hard dependency on that KMS key and the IAM policy guarding it — which is now part of your threat model.

storage "raft" {
  path    = "/vault/data"
  node_id = "vault-1"
}
 
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abcd-...";
}
 
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/tls/tls.crt"
  tls_key_file  = "/etc/vault/tls/tls.key"
}
# recovery keys (Shamir) still exist for break-glass even with auto-unseal.

HA, and the two kinds of replication

High availability is single-cluster: with Integrated Storage (Raft) an odd number of nodes elect a leader; the leader serves writes, followers stand by, and losing a minority of nodes is a non-event. Replication is cross-cluster and comes in two flavors. Disaster Recovery (DR) replication keeps a warm standby cluster byte-for-byte in sync — it serves nothing until you promote it, and exists purely for failover. Performance replication copies policies and backend config to other clusters that serve their own tokens and leases locally — it exists for scale and locality, not failover.

Why this matters for security, not just uptime: a DR secondary contains every secret, token, and lease your primary does, so it is exactly as sensitive as the primary and must be guarded identically — a common mistake is hardening the primary and leaving the DR cluster’s network and audit story as an afterthought. Snapshots are the same: a Raft snapshot is a full encrypted copy of Vault’s state, safe at rest but catastrophic if paired with access to the unseal path, so snapshots and seal keys must never share a blast radius.