The audit logs contain the full request and response objects for every interaction with Vault. The request and response can be matched utilizing a unique identifier assigned to each request.
Most strings contained within requests and responses are hashed with salt using HMAC-SHA256.
The purpose of the hash is so that secrets aren't in plaintext within your audit logs. However, you're still able to check the value of secrets by generating HMACs yourself; this can be done with the audit device's hash function and salt by using the /sys/audit-hash API endpoint (see this article for more details).
Note: Currently only strings coming from JSON or being returned in JSON are HMAC'd. Other data types, like integers, booleans, and so on, are passed through in plaintext.
While most strings are hashed, Vault does make some exceptions, such as auth and secrets, and users can enable additional exceptions using the auth/secret enable command, and then tune it afterward. This article elaborates on how to tune an auth method (taken approle as an example) so that the data stored in the file audit device is stored in plain text. To do that, we'll use -audit-non-hmac-request-keys and -audit-non-hmac-response-keys flags.
-
-audit-non-hmac-request-keys(string: "")- Key that will not be HMAC'd by audit devices in the request data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key. -
-audit-non-hmac-response-keys(string: "")- Key that will not be HMAC'd by audit devices in the response data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
Prerequisite
A running instance of Vault with Audits already enabled at the desired path. In my case, I've taken a file audit device enabled at /var/log/vault_audit.log. The same conditions are expected on all the Vault nodes as well as other DR/PR-Secondary clusters with appropriate permissions and settings set everywhere.
Setup
- Enable the approle auth method and tune it via the following command using non-hmac flags. Run:
vault auth tune -audit-non-hmac-request-keys=role_id \
-audit-non-hmac-request-keys=secret_id \
approle
# use -ns=<namespace_name> after vault auth tune, if the command to be run inside
a Vault namespace.
- Generate role_id and secret_id and login to Vault via approle for an audit log to generate and save in the audit log file.
vault write auth/approle/login \
role_id=da247451-d04b-c2ae-2cfd-47a399a8e149 \
secret_id=c94f1648-2b4e-c939-6c03-8326ef489475
Key Value
--- -----
token s.NsAcjXQk8Zd4PX42584kIdLF.74LXi
token_accessor DBE2Lujhg59qDJTTWCWTvPmp.74LXi
token_duration 20m
token_renewable true
token_policies ["default"]
identity_policies []
policies ["default"]
token_meta_role_name my-role
# use -ns=<namespace_name> after vault write, if the command to be run inside
a Vault namespace.
- Following is an audit log entry post the approle login.
cat vault_audit.log | grep role_id | tail -1 | jq
{
"time": "2022-07-16T16:12:16.728966496Z",
"type": "response",
"auth": {
"client_token": "hmac-sha256:3ab66bb88c60e6b3808b8187b6b6261058d3d9f67a64847e24e35914d0008138",
"accessor": "hmac-sha256:3ffa44162d0c51299655d7e1e25bfdb8b9933e612e3fcafcf297062f0cd1e005",
"display_name": "dpo-auth-approle",
"policies": [
"default"
],
"token_policies": [
"default"
],
"metadata": {
"role_name": "my-role"
},
"entity_id": "7aaab944-6779-9266-8dcd-c5a056316f81",
"token_type": "service",
"token_ttl": 1200
},
"request": {
"id": "b93aaf01-8d6c-ac4e-8cc8-caaa4630cab0",
"operation": "update",
"mount_type": "approle",
"client_token": "hmac-sha256:50044904d9145d06b4da2d3fad6fe916fe1ebce22edcf17f2a763ce70b8849f4",
"client_token_accessor": "hmac-sha256:b347d87d76ee15a0a3c614d35f66b5c53982007647e8e4d53812107e073d1a2e",
"namespace": {
"id": "74LXi",
"path": "dpo/"
},
"path": "auth/approle/login",
"data": {
"role_id": "da247451-d04b-c2ae-2cfd-47a399a8e149",
"secret_id": "c94f1648-2b4e-c939-6c03-8326ef489475"
},
"remote_address": "192.168.64.33"
},
"response": {
"auth": {
"client_token": "hmac-sha256:3ab66bb88c60e6b3808b8187b6b6261058d3d9f67a64847e24e35914d0008138",
"accessor": "hmac-sha256:3ffa44162d0c51299655d7e1e25bfdb8b9933e612e3fcafcf297062f0cd1e005",
"display_name": "dpo-auth-approle",
"policies": [
"default"
],
"token_policies": [
"default"
],
"metadata": {
"role_name": "my-role"
},
"num_uses": 10,
"entity_id": "7aaab944-6779-9266-8dcd-c5a056316f81",
"token_type": "service",
"token_ttl": 1200
},
"mount_type": "approle"
}
}
As you can see in the last snippet, role_id, and secret_id are stored in the audit log as plain text. You can match the value from the vault write auth/approle/login command.
Note: If you have a need to non-HMAC'd multiple data keys you can use the same flags multiple times in the command, each time with 1 key. For example:
vault auth tune -audit-non-hmac-request-keys=key1 \
-audit-non-hmac-request-keys=key2 \
-audit-non-hmac-request-keys=key3 \
-audit-non-hmac-request-keys=key4 \
approle
# use -ns=<namespace_name> after vault auth tune, if the command to be run inside
a Vault namespace.
You can also use log_raw while enabling the audit devices because of which all of the logs will be logged without being HMAC'd. Although, this is good to be used in Testing environments but strictly prohibited in Production environments.