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"
}
]
-