Vault Architecture: Server, Storage, and Seal

Vault's security guarantees come from a small set of well-thought-out architectural pieces. This lesson walks through them so you can reason about Vault's behaviour in any deployment.

The Vault Process

Vault is a single Go binary — vault — that runs as a long-lived server process. The same binary is also the CLI client: vault server, vault status, vault kv put.

The server exposes:

• HTTP API on port 8200 (used by CLI, SDKs, Web UI)
• Cluster port 8201 (used for HA replication between Vault nodes)

The Barrier

Vault's storage holds encrypted data. Between Vault's internals and the storage backend sits the barrier — every read decrypts on the way out, every write encrypts on the way in. The barrier uses AES-256-GCM with a key derived from the master key.

Vault Client
     │
     ▼
Vault Server  ──▶  [ Barrier ]  ──▶  Storage Backend (Raft / Consul / etc.)
                      ▲
                      │
              encryption key
                      ▲
                      │
              unseals via …

Sealed vs Unsealed

A freshly started Vault is sealed — it has no key in memory and cannot decrypt anything. You can talk to its API, but every meaningful request errors with "Vault is sealed".

To use Vault, you unseal it. Unsealing means providing enough material to reconstruct the master key in the server's memory. The master key never persists in unencrypted form.

Shamir's Secret Sharing

By default, the master key is split via Shamir's Secret Sharing into 5 shares with a threshold of 3 (5/3). You can change these (e.g., 7/4) at initialization.

To unseal, you provide 3 of the 5 shares. The server reconstructs the master key in memory; subsequent requests work.

$ vault operator init
Unseal Key 1: yYP...
Unseal Key 2: 5dT...
Unseal Key 3: hRm...
Unseal Key 4: 4Lz...
Unseal Key 5: 9Bk...
Initial Root Token: hvs.AbCdEf...

$ vault operator unseal yYP...   # 1/3
$ vault operator unseal 5dT...   # 2/3
$ vault operator unseal hRm...   # 3/3 → unsealed

Distribute the unseal keys to separate operators. No single person should hold three of them.

Auto-Unseal

Manual Shamir unseal does not scale — every restart, every new node, every failover requires humans with key shares. Production Vault uses auto-unseal: the master key is encrypted with a KMS key, stored in the storage backend, and Vault automatically decrypts it on startup via:

• AWS KMS
• Azure Key Vault
• GCP Cloud KMS
• HSM (Hardware Security Module, via PKCS#11)
• OCI KMS
• Transit (another Vault cluster, useful for testing)

The KMS key never leaves the KMS service. Vault's IAM identity (the EC2 role, Azure managed identity, GCP service account) authorizes the decrypt call. If someone steals your storage data without the KMS access, they have ciphertext only.

Storage Backends

Vault stores its (encrypted) data in a pluggable backend:

Integrated Storage (Raft) is HashiCorp's recommendation since Vault 1.4. It makes HA simple — 3 or 5 Vault nodes vote like any other Raft cluster, with no separate Consul cluster to operate.

HA and Active/Standby

In an HA cluster, exactly one Vault node is the active node — it handles all writes and reads. The others are standbys — they hold the data and forward requests to the active, or serve local reads in "performance standby" mode (Enterprise feature).

If the active node fails, the standbys hold an election (Raft) and one becomes the new active. Failover typically completes in seconds.

The Root Token

Initialisation produces an initial root token with unlimited privileges. Use it once to create your real admin users/policies, then revoke it:

$ vault token revoke -self

Production Vault should not have an active root token. If you ever need root, generate one temporarily using a quorum of unseal-key holders (vault operator generate-root), do your work, then revoke it.

Recovery Mode and Recovery Keys

When auto-unseal is enabled, the unseal keys are replaced by recovery keys — they are not used to unseal (the KMS does that automatically) but are required for sensitive operations like generating a new root token. Same Shamir mechanics, different purpose.

What the Audit Log Captures

Vault has pluggable audit devices (file, syslog, socket). Every request and response is logged with the requesting identity, the path, and the operation. Audit logs are hashed via HMAC to prevent secret leakage — you see that a value was written without seeing the value.

Enable audit before going live:

vault audit enable file file_path=/vault/audit.log

If all audit devices fail, Vault stops accepting requests — by design. Better to fail closed than silently lose audit evidence.

Putting It Together

You now have a mental model: a Vault server that boots sealed, unseals via Shamir (or KMS for auto-unseal), reads and writes encrypted data through the barrier into a storage backend (Raft preferred), handles HA via Raft election, and audits everything to a tamper-evident log. With this picture in mind, the next lessons — auth methods and policies — make sense as the front door to this system.