Understanding Vault Seal/Unseal: The Startup Flow Fundamentals

Vault always starts in a "Sealed" state right after the process boots. Only after an unseal opens the Barrier can it serve any secrets.

This article walks through the boot → unseal → HA activation flow and contrasts the Shamir (manual) approach with the KMS/HSM (Auto Unseal) approach, from both an operations and an exam-prep perspective.

The Big Picture: Startup Flow

Vault reads its config file and initializes storage (integrated Raft storage, Consul, etc.), the listener, and the "seal" stanza (Shamir by default). The process always boots Sealed, and the encryption Barrier must be opened via unseal before Vault can serve traffic.

Once unseal completes, HA setups run a leader election: one node becomes Active and the rest are Standby. With Auto Unseal, each node queries the KMS/HSM and opens the Barrier automatically — no manual intervention required.

• Process start → config load → storage connect (Raft/Consul, etc.)
• Apply the seal stanza (Shamir or KMS/HSM, etc.)
• State is Sealed (confirm with vault status)
• Unseal (manual or auto)
• Barrier decryption succeeds → Unsealed
• HA leader election (Active/Standby)

Vault startup → unseal → HA flow (conceptual diagram)

 [Client]
    |
[Vault Process] --read--> [Config: storage/listener/seal]
    |
    v
 [Sealed Barrier]
   / \
  /   \
manual  auto
(SHAMIR) (KMS/HSM)
  |         |
  v         v
[Unseal Shares t/n]   [KMS decrypt barrier key]
        \             /
         v           v
           [Barrier Opened]
                   |
                   v
             [HA Election]
              /         \
             v           v
         [Active]     [Standby]
            |            |
      serve writes   proxy/reads* (*構成による)

How Seal/Unseal Works Internally — Key Terminology

Vault encrypts data in storage with the "Barrier" and protects the key material that opens it. The master key generated at initialization (operator init) is split using Shamir's Secret Sharing (in the manual case). Once the threshold number of shares is supplied, the master key is reconstructed and the Barrier opens.

With Auto Unseal, an external key manager (KMS/HSM) protects and decrypts the master key, so the Barrier opens automatically at startup. In this mode Vault issues "Recovery Keys" instead, which are used for specific operations such as disaster recovery or generating a new root token.

• Sealed: the Barrier is closed and data in storage cannot be decrypted
• Unseal: the act of opening the Barrier — either by supplying the threshold (t/n) of unseal keys or via a KMS/HSM
• Shamir split: the key shares distributed for manual unseal (n shares total, t required)
• Auto Unseal: automatic decryption via KMS/HSM, where each node uses the external key at startup
• Recovery Keys: the shared keys distributed under Auto Unseal, used for maintenance operations like generate-root and rekey

Manual Unseal (Shamir): Step-by-Step Operations

Manual unseal requires entering threshold-many of the unseal keys produced at initialization to open the Barrier. In an HA cluster, every node must be unsealed individually (both Active and Standby).

Key management is the cornerstone of operations. Design the share count and threshold around your team size and BCP requirements, and plan for key storage, distribution, and rotation (rekey).

• Initialize the cluster exactly once. Double-initialization destroys data.
• Run unseal t times on each node and verify with vault status.
• Perform rekey within a safe maintenance window and revoke the old keys.

A typical manual unseal sequence (example)

# 初期化（共有数5、しきい値3）※クラスタで一度のみ
vault operator init -key-shares=5 -key-threshold=3
# => Unseal Key 1..5 と 初期rootトークンが出力される（安全に保管）

# Unseal（1台につき3回、異なるキーを入力）
vault operator unseal
vault operator unseal
vault operator unseal

# 状態確認
vault status
# Sealed: false になっていればUnseal完了

# しきい値の変更や共有の再生成（ローテーション）
vault operator rekey -key-shares=5 -key-threshold=3

# 手動で再Sealする場合（緊急時の遮断など）
vault operator seal

Designing and Configuring Auto Unseal (KMS/HSM)

Auto Unseal protects Vault's master key with an external KMS/HSM, so each node opens the Barrier automatically at startup. It reduces manual operations and the burden of restarts and scale-out events.

Under this model, Vault issues Recovery Keys instead of unseal keys. They are required for specific maintenance operations such as generate-root and recovery rekey, so design a clear distributed-storage policy for them.

• Reachability and authorization (IAM, Service Principal, etc.) from every node to the KMS/HSM is mandatory
• If the KMS is down, newly started nodes cannot unseal — though nodes that were already unsealed keep running
• Align your cloud KMS key-rotation policy with Vault's rekey procedure
• Auditing: make sure you can correlate Vault audit-device logs with KMS access logs

Auto Unseal configuration snippet (AWS KMS example)

# /etc/vault.d/config.hcl（抜粋）
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 0
  tls_cert_file = "/etc/vault.d/certs/server.crt"
  tls_key_file  = "/etc/vault.d/certs/server.key"
}

seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

api_addr = "https://vault-1.example.com:8200"
cluster_addr = "https://vault-1.example.com:8201"

HA Clusters and Unseal

In an HA setup (Raft/Consul), every node is expected to be unsealed. The Active node leads writes, and Standbys proxy requests or serve reads (depending on configuration and features). Nodes that remain sealed cannot join the cluster and undermine failover resilience.

With Auto Unseal, each node queries the KMS/HSM independently and unseals itself. With manual unseal, every node needs the threshold number of key entries. For rolling restarts, either automating unseal (Auto Unseal) or maintaining a solid runbook pays off.

• Initialize exactly once. New nodes added later join the cluster first, then unseal
• Bake status monitoring (Sealed, HA Mode, Active/Standby) into your health checks
• Periodically run restart drills to validate the health of your unseal path (manual or KMS)

Example: checking HA status

# HA/Barrierの状態確認
vault status
# 出力例
# Sealed: false
# HA Enabled: true
# HA Cluster: https://vault-1.example.com:8201
# HA Mode: active  （他ノードは standby）

Exam-Prep Highlights and a Side-by-Side Comparison

For Associate and Ops exams, common topics include the differences between manual and Auto Unseal, the t/n threshold, the per-node unseal requirement in HA, and behavior during a KMS outage. Lock in the basics of operator init / unseal / rekey / seal / status, and make sure you can distinguish the role of "Recovery Keys" under Auto Unseal (used for generate-root and recovery rekey).

In production, clearly define the threshold based on BCP requirements, document key custody and procedures, and monitor KMS reachability (VPC endpoints, firewalls).

• Manual unseal is a human operation; Auto Unseal depends on an external KMS/HSM
• Every node must be unsealed (both Active and Standby)
• Never initialize twice. Run regular backup and DR drills

Check Your Understanding

Frequently Asked Questions