Is Vault sealed? — first tool + proof field

1. Why “is it sealed?” is five questions

Concept: operators collapse five failures into one sentence. The node is sealed. The client is talking to a standby. The ACL never granted that path. The AppRole mount is missing. The lease expired ten minutes ago. Those are five first tools.

Path: write the failing identity, the path, and the UTC window. Then pick the tool that is allowed to answer the question. Do not open Shamir shares until Sealed is true.

Do: this page is the night-shift desk for proof. The factory taught the gates — unseal, token, ACL, namespace, leader. Here you learn the five official surfaces you actually open, in order, when someone asks you to prove Vault is working or to explain why there is no secret.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you type. Each tool is allowed to prove one thing. Over-claiming a field is how you reseal a healthy cluster at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open a policy PR until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the on-call laptop. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the node and that you can even investigate. Side B proves the identity door and the ACL. Side C proves remaining life and the paper trail. On a messy Sev-2, do them in this order until a field lights up.

Side A — Node: status + audit device

1. Run vault status on the address the client uses

   Official: the status command prints whether Vault is sealed and whether HA mode is enabled, even when the node is sealed. Exit codes: 0 unsealed, 1 error, 2 sealed. Quote the table, not only the exit. Source: status — Command.

2. Read Sealed, then HA Mode

   Sealed = false means the node is unsealed and ready to operate; true means you still need unseal. On an HA cluster also quote HA Enabled, HA Mode (active or standby), and HA Cluster. A standby that receives a write will forward (default) or return 307 to the active node’s api_addr if forwarding is off or the client sent X-Vault-No-Request-Forwarding. Source: status output fields; High availability mode (HA).

3. If Sealed is true, stop the policy hunt

   Official seal concept: prior to unsealing, the only possible operations are to unseal Vault and check status. Shamir threshold or auto-unseal is change-control. Do not invent a policy bug on a sealed node.

4. Confirm an audit device exists before you promise a name

   vault audit list (add -detailed for file_path and replication). Official example: Path file/, Type file. A new cluster starts with auditing disabled. Empty list → you cannot prove who read the secret; enabling a device now only helps the next call. Source: audit list; Audit logging.

vault-lab $ vault status
Key                     Value
---                     -----
Seal Type               shamir
Initialized             true
Sealed                  false
Total Shares            5
Threshold               3
Version                 1.17.2
Storage Type            raft
Cluster Name            vault-lab
HA Enabled              true
HA Mode                 active
Active Since            2026-08-15T18:48:04Z
Raft Committed Index    1842
Raft Applied Index      1842

Side B — Identity door + ACL (auth method, policy)

1. List auth methods before you blame AppRole

   vault auth list. Official columns: Path, Type, Description. Detailed view adds Default TTL, Max TTL, Token Type, Replication, Accessor. Auth methods must be enabled; the same type can be mounted at different paths. Login lives under that path (for example auth/approle/login). Source: auth list; Authentication.

2. Lookup the token the job actually holds

   vault token lookup (self) or lookup by accessor. Quote policies, ttl, path (e.g. auth/approle/login), display_name, renewable, type. Do not lookup your personal token and call it the pipeline. Source: token lookup.

3. Read the named ACL — path plus capabilities

   vault policy read finance-read or UI Policies → ACL Policies. Policies are deny-by-default. Quote the HCL path and capabilities list. On KV v2 the HTTP payload is secret/data/<name> even when the CLI is vault kv get secret/<name>. A policy written only on secret/finance/* does not grant the v2 data path. deny always wins. Generating database credentials is a GET → you grant read, not create. Source: Policies.

4. If login itself fails, read the role, not Slack

   Example: vault read auth/approle/role/app-finance. Quote token_ttl, secret_id_ttl, and attached policies. Auth identities have leases too — you must reauthenticate after the lease, or renew with vault token renew. Source: Authentication — Auth leases; AppRole is one of the documented machine auth methods.

Side C — Remaining life + paper trail (lease, audit row)

1. If the secret is dynamic, lookup the lease_id

   Official: every dynamic secret and every service token gets a lease. vault read returns lease_id. Then vault lease lookup <id>. Quote expire_time, id, issue_time, last_renewal, renewable, ttl. Renew with an increment from now, not from the old expiry, and inspect the new TTL — the backend may ignore your increment. Prefix revoke: vault lease revoke -prefix database/. UI: Access tab. Source: Lease, renew, and revoke; lease command.

2. If the secret is KV, lookup the token TTL instead

   KV does not issue leases. A “secret expired” story on secret/finance/db is either a dead token (vault token lookup → ttl) or a version/path bug. Do not run lease lookup on a KV path and call it proof.

3. If GRC asked who, read one audit JSON line

   Official schema: one JSON object per line. Quote type (request / response), time, auth.display_name, auth.policies, request.path, request.operation, and error when present. String values are HMAC-SHA256 by default — use /sys/audit-hash to match a known value. kv get is the payload, not the accessor history. Source: Audit logging; Audit log entry schema.

{
  "type": "response",
  "time": "2026-08-16T02:11:04Z",
  "auth": {
    "display_name": "approle-app-finance",
    "policies": ["default", "finance-read"],
    "token_type": "service"
  },
  "request": {
    "operation": "read",
    "path": "secret/data/hr/db"
  },
  "error": "1 error occurred:\n\t* permission denied\n\n"
}

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times, IPs, and identities below are lab-only.

Journey · one amber hop is the ticket

vault-lab $ vault policy read finance-read
path "secret/data/finance/*" {
  capabilities = ["read"]
}
path "secret/metadata/finance/*" {
  capabilities = ["list"]
}

vault-lab $ vault audit list
Path     Type    Description
----     ----    -----------
file/    file    n/a

vault-lab $ vault audit list -detailed
Path     Type    Description    Replication    Options
----     ----    -----------    -----------    -------
file/    file    n/a            replicated     file_path=/var/log/vault_audit.log

vault-lab $ vault auth list
Path           Type          Description
----           ----          -----------
approle/       approle       n/a
kubernetes/    kubernetes    n/a
token/         token         token based credentials

vault-lab $ vault lease lookup database/creds/readonly/27e1b9a1-27b8-83d9-9fe0-d99d786bdc83
Key             Value
---             -----
expire_time     2026-08-16T02:04:10Z
id              database/creds/readonly/27e1b9a1-27b8-83d9-9fe0-d99d786bdc83
issue_time      2026-08-16T01:44:10Z
last_renewal    <nil>
renewable       true
ttl             0s

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• Vault docs — status command (Sealed, HA Enabled, HA Mode, exit 0 / 1 / 2, raft fields)
• Vault docs — Seal/Unseal (only unseal and status while sealed)
• Vault docs — High availability mode (HA) (active / standby, request forwarding, 307, api_addr)
• Vault docs — Audit logging (file / syslog / socket; disabled at init; availability; HMAC; exempted endpoints)
• Vault docs — File audit device (file_path)
• Vault docs — Audit log entry schema (JSON lines; request.path, auth.display_name)
• Vault docs — audit list (Path / Type; -detailed)
• Vault docs — Policies (deny-by-default; path + capabilities; KV v2 /data/; deny wins)
• Vault docs — policy read
• Vault docs — Authentication (enable at a path; tokens; auth leases)
• Vault docs — auth list (Path / Type / Description)
• Vault docs — token lookup
• Vault docs — Lease, renew, and revoke (dynamic secrets + service tokens; KV has no lease; UI Access tab)
• Vault docs — lease command (expire_time, ttl, renewable)
• Vault docs — KV v2 (API path /data/)
• Vault docs — Vault UI (UI at /ui; manage policies and secrets engines)

Related: Blog 1 · Session factory — unsealed ≠ enough · HashiCorp Vault interview hub · Policy and namespace design · AppRole secret-zero · Dynamic secrets and leases · Audit device / SIEM pipeline