Sealing Vault

Avatar
Brian Shumate
  • Updated

One of Vault’s cornerstone features is the concept of its seal. Vault starts in a sealed state and is essentially unusable until it is unsealed.

Once unsealed and operational, an operator with sufficient privilege can immediately seal Vault as necessary. Sealing Vault places it into a state where it accepts only unauthenticated instructions such as those for status and unsealing, and is often a common first step in responding to a security incident, for example.

An operator with sufficient privilege can seal Vault using the following methods:

Regardless of the method used, Vault will log information about a successful seal operation in both the Audit Device log and the operational log.

Audit Device Log Entry

Here is an example audit device log entry for a successful seal operation:

{
  "time": "2018-08-28T17:59:16.2412002Z",
  "type": "request",
  "auth": {
    "client_token": "hmac-sha256:c703d5a6e224bdd8c9c95f6b1b17ca1be82e30e197f844dc4ed62afee927fe6e",
    "accessor": "",
    "display_name": "root",
    "policies": [
      "root"
    ],
    "token_policies": [
      "root"
    ],
    "metadata": null,
    "entity_id": ""
  },
  "request": {
    "id": "a6d0437d-eded-4da7-8314-88d94258aab9",
    "operation": "update",
    "client_token": "hmac-sha256:c703d5a6e224bdd8c9c95f6b1b17ca1be82e30e197f844dc4ed62afee927fe6e",
    "client_token_accessor": "hmac-sha256:24f5346546cf33f674ce4a2cf238ccd88d0f3fcfc6545187540587c4b5b1560e",
    "namespace": {
      "id": "root",
      "path": ""
    },
    "path": "sys/seal",
    "data": null,
    "policy_override": false,
    "remote_address": "172.17.0.1",
    "wrap_ttl": 0,
    "headers": {}
  },
  "error": ""
}

Some key fields which appear in the relevant audit log entry example:

  • time represents the moment in time when the seal operation was requested
  • display_name is a human-friendly name associated with the token used in the seal request
  • path is representative of the API path and for seal operations will always be /sys/seal
  • remote_address: The IP address of the client that initiated the seal; note that this value will not represent the true client IP address if using a load balancer without PROXY protocol or X-Forwarded-For headers in use

See Audit Log Notes for more details about the audit log format and fields.

Operational Log Entry

Here is an example extract from Vault’s operational logging that shows a successful seal operation:

2018-08-28T17:59:16.244Z [DEBUG] core: marked as sealed
2018-08-28T17:59:16.244Z [DEBUG] core: clearing forwarding clients
2018-08-28T17:59:16.245Z [DEBUG] core: done clearing forwarding clients
2018-08-28T17:59:16.245Z [DEBUG] core: finished triggering standbyStopCh for runStandby
2018-08-28T17:59:16.245Z [DEBUG] core: closed perf standby
2018-08-28T17:59:16.245Z [DEBUG] core: closed periodic license refresh stop channel
2018-08-28T17:59:16.245Z [DEBUG] core: shutting down periodic key rotation checker
2018-08-28T17:59:16.245Z [DEBUG] core: shutting down periodic leader refresh
2018-08-28T17:59:16.245Z [DEBUG] core: shutting down leader elections
2018-08-28T17:59:16.246Z [INFO ] core: pre-seal teardown starting
2018-08-28T17:59:16.262Z [INFO ] core: stopping replication
2018-08-28T17:59:16.262Z [INFO ] core: closed sync connection
2018-08-28T17:59:16.263Z [INFO ] core: replication stopped
2018-08-28T17:59:16.263Z [INFO ] core: stopping cluster listeners
2018-08-28T17:59:16.263Z [DEBUG] core: waiting for success notification while stopping cluster listeners
2018-08-28T17:59:16.263Z [INFO ] core: shutting down forwarding rpc listeners
2018-08-28T17:59:16.263Z [INFO ] core: forwarding rpc listeners stopped
2018-08-28T17:59:16.487Z [DEBUG] replication.index.perf: saved checkpoint: num_dirty=48
2018-08-28T17:59:16.514Z [DEBUG] replication.index.local: saved checkpoint: num_dirty=0
2018-08-28T17:59:16.514Z [DEBUG] replication.index.periodic: starting WAL GC: from=196 to=232 last=488
2018-08-28T17:59:16.526Z [INFO ] core: rpc listeners successfully shut down
2018-08-28T17:59:16.526Z [INFO ] core: cluster listeners successfully shut down
2018-08-28T17:59:16.526Z [DEBUG] audit: removing reload function: path=file/
2018-08-28T17:59:16.526Z [DEBUG] expiration: stop triggered
2018-08-28T17:59:16.526Z [DEBUG] expiration: finished stopping
2018-08-28T17:59:16.526Z [INFO ] rollback: stopping rollback manager
2018-08-28T17:59:17.420Z [DEBUG] replication.index.perf: saved checkpoint: num_dirty=0
2018-08-28T17:59:17.430Z [DEBUG] replication.index.local: saved checkpoint: num_dirty=0
2018-08-28T17:59:17.430Z [DEBUG] sealwrap: stopping upgrades
2018-08-28T17:59:17.431Z [DEBUG] core: set storage to read-write
2018-08-28T17:59:17.431Z [INFO ] core: pre-seal teardown complete
2018-08-28T17:59:17.447Z [DEBUG] core: runStandby done
2018-08-28T17:59:17.451Z [DEBUG] core: sealing barrier
2018-08-28T17:59:17.454Z [INFO ] core: vault is sealed

Of importance to note here first off is the line:

2018-08-28T17:59:16.244Z [DEBUG] core: marked as sealed

This is the moment that the successful seal operation begins. It is only logged at the DEBUG level in versions of Vault up to and including v0.11.0.

For versions of Vault following v0.11.0, the same line will be logged at INFO level instead:

2018-08-28T17:59:16.244Z [INFO] core: marked as sealed

Once Vault is fully sealed, the last log line is emitted:

2018-08-28T17:59:17.454Z [INFO ] core: vault is sealed

Vault has completed the seal process and is now sealed. It must be unsealed to restore operational status.

Resources

  1. Seal/Unseal
  2. /sys/seal API
  3. operator seal CLI
  4. Audit Device log
  5. /sys/unseal API
  6. operator unseal CLI

Articles in this section

See more

Related articles