Production installations of Vault typically operate with one or more enabled audit devices which log details of all external requests and responses for the specific purpose of performing audits on those data.
NOTE: audit device logs are a separate and unrelated concept from Vault's operational logs, which are typically gathered by the operating system journal from standard output and standard error while Vault is running and contain a different set of information.
You can enable an audit device for output to a variety of destinations including static files, TCP, UDP, or Unix sockets, and syslog. Regardless of the configured destination, the resulting output is always in JSON format.
More details including an example audit device log entry can be found in the Troubleshooting Vault tutorial.
»Challenge
Audit device logs provide great details for troubleshooting, such as counts for operations against a specific Vault endpoint or the IP addresses of hosts responsible for generating specific errors.
These logs can be aggregated into a solution for human consumption with dashboards and querying, but without access to this solution it can be useful to have an alternative means of querying the logs in an ad-hoc manner during troubleshooting scenarios.
»Solution
The log file from an enabled File Audit Device can be queried in an ad-hoc manner using a common command line tool. Important details which could help resolve the troubleshooting scenario can still be accessed from the audit device log when other solutions for querying aggregated logs are unavailable.
»Notes and prerequisites
This tutorial explains how to query the logs written by a File Audit Device using the popular command line utility jq for data points found only in these logs which can be useful in troubleshooting.
To follow along with this tutorial you need the following.
- Download the example log file from vault-guides
- Install jq if not already installed
NOTE: This tutorial is written with examples for the Linux operating system, but the same principles can be applied in other operating systems and jq is a cross platform tool so these examples will work on other platforms as well.
»Example log file preparation
Whenever an audit device log filename is referenced in examples, it will appear as $AUDIT_LOG_FILE; you should replace this value with the actual filename of the audit device log from the vault-guides repository so that examples work as-is.
First, clone the repository.
Then export the AUDIT_LOG_FILE environment variable to the example log file path.
You are now prepared to try the examples shown in this tutorial.
»All errors and their timestamps
To begin with a simple example, you can list all non-null error fields along with their corresponding timestamps to quickly gain insight into the volume and type of errors logged by the audit device.
If this command returns nothing, then there are no errors present in the log file, otherwise results would resemble this example.
In this simple example, you can observe that there are just a few errors which break down as follows:
- "permission denied": The client token used in the request lacks the required capabilities for the requested endpoint; this is perhaps the most common error you will encounter in audit device logs
- "missing client token": A request to an authenticated endpoint was made without providing a client token
- "unsupported path": A request was made against an auth method or secrets engine using an unsupported endpoint path (likely due to typo)
TIP: While this is just a simple and compact example of errors for the purpose of this tutorial, you can expect to find a much larger volume of more varied errors in a heavily used Vault environment.
»HMAC hashed errors and their timestamps
Sensitive information, including details returned in errors are all hashed with a salt using HMAC-SHA256 according to the Sensitive Information section of the Audit Devices documentation.
To locate these hashed errors and their timestamps, use a query like this example.
The results show a few HMAC hashed errors, which appear as the hash algorithm type and the actual hashed information separated by a colon.
You can use the hashed values compared against previously known error payloads to find matches.
For a simple example, suppose that you had a number of AppRole auth method login failures due to the error "invalid secret id", these would be included in the .response.data.error field and would be hashed.
If you want to find the corresponding entries in the audit device log, you can use the /sys/audit-hash API to compare a known value with the hashes to find matches. Be sure to review the API documentation for more details.
»HMAC hash calculation example
NOTE: The HMAC used by an audit device is unique to that device. The example is provided here only for reference to the process involved to calculate a hash using the sys/audit-hash API.
From the previous example output, note that the second and third entries have the same hash value (hmac-sha256:8c436a490d2dd8e2410c5a67d2e2663a09f2e0e861cb4dbf6c224d02cc84f2e3).
Assuming that a file audit device is enabled at the file path, here is an example vault command to compare this hash value with the string "invalid secret id" to learn if the two match.
The command writes to the API and specifies the file audit device as the last part of the path to select the correct audit device for calculating hashes against, and provide the string "invalid secret id" as the value of input.
Successful response:
In the case of this example there is a match. You can conclude that the last 2 of the 3 example HMAC hashed error lines indeed contain the error "invalid secret id".
Again, you will need to use this technique on logs for which you still have access to the audit device that wrote them to successfully calculate hashes.
»Counts and specific details
Sometimes being able to group related items from the audit device logs by their count is helpful to spot outliers and other problems.
»Count all requests and responses
You can count the occurrences of requests and responses like this.
This combined number of requests and responses (1397) should equal the total lines in the file as shown by counting lines for example, with the wc command.
Successful output:
»Response display names
To break out the authentication display name counts for responses, you can use something like this example query which sets up a map of display names and counts where the values are not null.
Successful output:
It is evident from this output that the busiest display names accessing this Vault are token, token-lab-admins and userpass-lab-user-7.
»Request operations
This query will break out all request operation types by count.
Successful output:
From this output, you can observe that most operations against this Vault server during the time period covered by the audit device logs are update and read, followed by create, and list, but with very few delete operations occurring during the same time period.
»Request paths
Learning about hot API endpoints by counting their requests for access can be helpful for troubleshooting. Let's take a look at the top 5 most busy endpoints based on their request counts.
Successful output:
From this output you know that the hottest path represented by these logs is auth/userpass/login/lab-user-7 with 204 requests. This is representative of the lab-user-7 authenticating with the username and password auth method.
»Errors by count
You can query for errors and get their counts like this.
Successful output:
Of note here, there are 1386 successful requests (where the error value is null) and 7 error occurrences. The "permission denied" errors are the result of using a token with insufficient capabilities to access and endpoint and you can view the complete request and response example to learn more about them.
The errors containing an asterisk (*) character originate from the logical backend (auth method or secrets engine).
The first, "permission denied" is a permission denied error resulting from an attempt to access a list of enabled secrets engines. The second, "unsupported path" is from an attempt to list an unsupported endpoint in the AppRole auth method.
Finally, the "missing client token" resulted from an attempt to access an authenticated endpoint without providing a valid client token.
»Remote address by count
It can be handy to know the request frequency by the value of the remote_address field in situations where inexplicable activity is occurring at a high volume, for example. This can help to identify the responsible host(s) for correction or mitigation of the issue.
Successful output:
In the above example, a clear outlier is 10.10.42.222, as it has generated the majority of requests.
»Path access by remote address
For a more complex query that breaks down API path access by count over each remote address, try this example. It produces a great deal of output, but you can use what you have learned here to modify it to return only the top 5 hottest paths for each host, for example.
Successful output:
»Tips
- Feel free to browse the example log file in your favorite JSON exploration tool to get an idea of the shape and structure of audit device data, the fields contained, and so on. It will help you later to quickly identify key areas when interpreting data from the logs.
- Explore the jq manual to learn about building more advanced and specific queries
»Summary
In this tutorial, you learned how to use a common command-line utility to query a file audit device log. You can use what you have learned here to expand your understanding of the Vault audit device logs and as a tool for troubleshooting scenarios.
