Most Vault audit log' strings contained within requests and responses are hashed with HMAC-SHA256. The purpose of the hash value is so that secrets aren't in plaintext within your audit logs. However, you're still able to check the value of secrets.
* Note: Please use methods below with cautious for production environment since audit log contain sensitive information of Vault.
1. Set log_raw=true, this flag can set logs the security sensitive information without hashing, in the raw format. Please be mindful with using this method on production environment:
vault audit enable file file_path=./vault_pr/audit_raw.log \
log_raw=true
2. Vault Audit log does make some exceptions for auth and secrets, vault users can enable additional exceptions using the vault secrets/auth tune command with flags -audit-non-hmac-request-keys -audit-non-hmac-response-keys to un-hash value:
vault secrets tune \
-audit-non-hmac-request-keys=password userpass/
vault auth tune \
-audit-non-hmac-request-keys=value1 -audit-non-hmac-request-keys=value2 github/
* Note: audit-non-hmac options only apply to thedataobject withinrequestorresponse objects. non-hmac option does not have affect on other object such as client_token, client_token_accessor etc.
3. Using /sys/audit-hash endpoint to calculate HMAC value is like reverse engineering, vault user can use a known plaintext (vault error messages) to calculate into its hash value.
Assuming that a file audit device is enabled at the file path, vault user want to know the hash value of plaintext "unsupported path":
❯ vault write sys/audit-hash/file input="unsupported path"
Key Value
--- -----
hash hmac-sha256:49acd61e270e6c3172886fd3e13ece3f1a8157dfd5f6fff99b779e574e54e84d
Then vault user can use this newly calculated hash value to find if there is a match from audit log.