Identifying Vault Seal type mechanisms in run-time – HashiCorp Help Center

Introduction

The Seal type mechanism is configurable at startup of Vault process or during a Seal migration. When a Vault server is started, it starts in a sealed state. In this state, Vault is configured to know where and how to access the physical storage, but doesn't know how to decrypt any of it.
The Seal type mechanism is captured at the startup of the Vault server with log_level=DEBUG.

Unsealing is the process of obtaining the plaintext root key necessary to read the decryption key to decrypt the data, allowing access to the Vault.

Almost no operations are possible prior to unsealing Vault. For example attempting to long in or authenticate, managing the mount tables or other requests that typical work when Vault is unseal will not be possible. During sealed states - it's only possible to unseal or otherwise perform a health or status check of of the seal.
The Seal mechanism could be changed during a Seal migration. However, during the Seal migration process the runtime details for Seal mechanism are not available.

Considerations

The information related to Vault Seal type is available on reading the configuration of the Vault server. In some specific cases, if the configuration is altered for a Seal migration, then the runtime information is required.
The Seal type is available via /sys/config/state/sanitized endpoint.

Different Approach

Approach 1: Vault server startup messages in the Vault operational logs

Enable the log_level=DEBUG following Vault Configuration
- At startup of the Vault server the output contains the Seal mechanism

# // output from the Vault operational logs are usually on a single line 
# // and here we've split them for better readability.

Oct 02 13:31:46 vault-test vault[2670]:
   2023-10-02T13:31:46.108+0200 [DEBUG] core: set config: sanitized 
   config={"api_addr":"https://192.168.200.5:8200","cache_size":0,
      "cluster_addr":"https://192.168.200.5:8201","cluster_cipher_suites":"",
      "cluster_name":"cluster-eu-west-1","default_lease_ttl":0,
      "default_max_request_duration":0,"disable_cache":false,
      "disable_clustering":false,"disable_indexing":false,
      "disable_mlock":false,"disable_performance_standby":false,
      "disable_printable_check":false,"disable_sealwrap":false,
      "disable_sentinel_trace":false,"enable_ui":true,
      "listeners":[{"config":{"address":"0.0.0.0:8200",
      "tls_cert_file":"/etc/vault.d/tls.crt","tls_key_file":"/etc/vault.d/tls.key"},
      "type":"tcp"}], "log_format":"unspecified",
      "log_level":"DEBUG","max_lease_ttl":0,"pid_file":"",
      "plugin_directory":"", "raw_storage_endpoint":true,
      "seals":[{"disabled":false,"type":"awskms"}],
      "storage":{"cluster_addr":"https://192.168.200.5:8201",
      "disable_clustering":false,"redirect_addr":
      "https://192.168.200.5:8200","type":"raft"}}

Approach 2: Reading sys/config/state/sanitized

Using a (root) Privileged Token read the seal mechanism using:

vault read -field=seals -format=json sys/config/state/sanitized

The output can resemble:

[
  {
   "disabled": false,
   "type": "awskms"
  }
]

Additional Information