2015-04-20 05:59:39 +00:00
---
2020-01-18 00:18:09 +00:00
layout: docs
page_title: File - Audit Devices
description: The "file" audit device writes audit logs to a file.
2015-04-20 05:59:39 +00:00
---
2017-09-08 02:38:47 +00:00
# File Audit Device
2015-04-20 05:59:39 +00:00
2017-09-08 02:38:47 +00:00
The `file` audit device writes audit logs to a file. This is a very simple audit
device: it appends logs to a file.
2016-09-30 19:08:38 +00:00
2017-09-08 02:38:47 +00:00
The device does not currently assist with any log rotation. There are very
2016-09-30 19:08:38 +00:00
stable and feature-filled log rotation tools already, so we recommend using
existing tools.
2017-09-08 02:38:47 +00:00
Sending a `SIGHUP` to the Vault process will cause `file` audit devices to close
and re-open their underlying file, which can assist with log rotation needs.
2015-04-20 05:59:39 +00:00
2017-09-08 02:38:47 +00:00
## Examples
2015-04-20 05:59:39 +00:00
2017-09-08 02:38:47 +00:00
Enable at the default path:
2015-04-20 05:59:39 +00:00
2020-05-21 17:18:17 +00:00
```shell-session
2017-09-08 02:38:47 +00:00
$ vault audit enable file file_path=/var/log/vault_audit.log
```
2015-04-20 05:59:39 +00:00
2017-09-08 02:38:47 +00:00
Enable at a different path. It is possible to enable multiple copies of an audit
device:
2015-04-20 05:59:39 +00:00
2020-05-21 17:18:17 +00:00
```shell-session
2017-09-08 02:38:47 +00:00
$ vault audit enable -path="vault_audit_1" file file_path=/home/user/vault_audit.log
2016-03-12 02:14:39 +00:00
```
2019-01-04 19:45:50 +00:00
Enable logs on stdout. This is useful when running in a container:
2020-05-21 17:18:17 +00:00
```shell-session
2019-01-04 19:45:50 +00:00
$ vault audit enable file file_path=stdout
```
2017-09-08 02:38:47 +00:00
## Configuration
2015-04-20 05:59:39 +00:00
2018-01-15 20:19:28 +00:00
Note the difference between `audit enable` command options and the `file` backend
configuration options. Use `vault audit enable -help` to see the command options.
2015-04-20 05:59:39 +00:00
Add option 'elide_list_responses' to audit backends (#18128)
This PR relates to a feature request logged through HashiCorp commercial
support.
Vault lacks pagination in its APIs. As a result, certain list operations
can return **very** large responses. The user's chosen audit sinks may
experience difficulty consuming audit records that swell to tens of
megabytes of JSON.
In our case, one of the systems consuming audit log data could not cope,
and failed.
The responses of list operations are typically not very interesting, as
they are mostly lists of keys, or, even when they include a "key_info"
field, are not returning confidential information. They become even less
interesting once HMAC-ed by the audit system.
Some example Vault "list" operations that are prone to becoming very
large in an active Vault installation are:
auth/token/accessors/
identity/entity/id/
identity/entity-alias/id/
pki/certs/
In response, I've coded a new option that can be applied to audit
backends, `elide_list_responses`. When enabled, response data is elided
from audit logs, only when the operation type is "list".
For added safety, the elision only applies to the "keys" and "key_info"
fields within the response data - these are conventionally the only
fields present in a list response - see logical.ListResponse, and
logical.ListResponseWithInfo. However, other fields are technically
possible if a plugin author writes unusual code, and these will be
preserved in the audit log even with this option enabled.
The elision replaces the values of the "keys" and "key_info" fields with
an integer count of the number of entries. This allows even the elided
audit logs to still be useful for answering questions like "Was any data
returned?" or "How many records were listed?".
2023-01-11 21:15:52 +00:00
The `file` audit device supports the common configuration options documented on
2023-01-26 00:12:15 +00:00
the [main Audit Devices page](/vault/docs/audit#common-configuration-options), and
Add option 'elide_list_responses' to audit backends (#18128)
This PR relates to a feature request logged through HashiCorp commercial
support.
Vault lacks pagination in its APIs. As a result, certain list operations
can return **very** large responses. The user's chosen audit sinks may
experience difficulty consuming audit records that swell to tens of
megabytes of JSON.
In our case, one of the systems consuming audit log data could not cope,
and failed.
The responses of list operations are typically not very interesting, as
they are mostly lists of keys, or, even when they include a "key_info"
field, are not returning confidential information. They become even less
interesting once HMAC-ed by the audit system.
Some example Vault "list" operations that are prone to becoming very
large in an active Vault installation are:
auth/token/accessors/
identity/entity/id/
identity/entity-alias/id/
pki/certs/
In response, I've coded a new option that can be applied to audit
backends, `elide_list_responses`. When enabled, response data is elided
from audit logs, only when the operation type is "list".
For added safety, the elision only applies to the "keys" and "key_info"
fields within the response data - these are conventionally the only
fields present in a list response - see logical.ListResponse, and
logical.ListResponseWithInfo. However, other fields are technically
possible if a plugin author writes unusual code, and these will be
preserved in the audit log even with this option enabled.
The elision replaces the values of the "keys" and "key_info" fields with
an integer count of the number of entries. This allows even the elided
audit logs to still be useful for answering questions like "Was any data
returned?" or "How many records were listed?".
2023-01-11 21:15:52 +00:00
these device-specific options:
2019-01-04 19:45:50 +00:00
- `file_path` `(string: <required>)` - The path to where the audit log will be
written. If a file already exists at the given path, the audit backend will
append to it. There are some special keywords:
- `stdout` writes the audit log to standard output
- `discard` writes output (useful in testing scenarios)
- `mode` `(string: "0600")` - A string containing an octal number representing
the bit pattern for the file mode, similar to `chmod`. Set to `"0000"` to
prevent Vault from modifying the file mode.
2019-10-15 14:20:51 +00:00
## Log File Rotation
To properly rotate Vault File Audit Device log files on BSD, Darwin, or Linux-based Vault servers, it is important that you configure your log rotation software to send the `vault` process a signal hang up / `SIGHUP` after each rotation of the log file.