1c7157e632
with a new endpoint '/sys/audit-hash', which returns the given input string hashed with the given audit backend's hash function and salt (currently, always HMAC-SHA256 and a backend-specific salt). In the process of adding the HTTP handler, this also removes the custom HTTP handlers for the other audit endpoints, which were simply forwarding to the logical system backend. This means that the various audit functions will now redirect correctly from a standby to master. (Tests all pass.) Fixes #784
70 lines
2.7 KiB
Markdown
70 lines
2.7 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Audit Backends"
|
|
sidebar_current: "docs-audit"
|
|
description: |-
|
|
Audit backends are mountable backends that log requests and responses in Vault.
|
|
---
|
|
|
|
# Audit Backends
|
|
|
|
Audit backends are the components in Vault that keep a detailed log
|
|
of all requests and response to Vault. Because _every_ operation with
|
|
Vault is an API request/response, the audit log contains _every_ interaction
|
|
with Vault, including errors.
|
|
|
|
Vault ships with multiple audit backends, depending on the location you want
|
|
the logs sent to. Multiple audit backends can be enabled and Vault will send
|
|
the audit logs to both. This allows you to not only have a redundant copy,
|
|
but also a second copy in case the first is tampered with.
|
|
|
|
## Sensitive Information
|
|
|
|
The audit logs contain the full request and response objects for every
|
|
interaction with Vault. The data in the request and the data in the
|
|
response (including secrets and authentication tokens) will be hashed
|
|
with a 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 backend's hash
|
|
function and salt by using the `/sys/audit-hash` API endpoint (see the
|
|
documentation for more details).
|
|
|
|
## Enabling/Disabling Audit Backends
|
|
|
|
When a Vault server is first initialized, no auditing is enabled. Audit
|
|
backends must be enabled by a root user using `vault audit-enable`.
|
|
|
|
When enabling an audit backend, options can be passed to it to configure it.
|
|
For example, the command below enables the file audit backend:
|
|
|
|
```
|
|
$ vault audit-enable file path=/var/log/vault_audit.log
|
|
...
|
|
```
|
|
|
|
In the command above, we passed the "path" parameter to specify the path
|
|
where the audit log will be written to. Each audit backend has its own
|
|
set of parameters. See the documentation to the left for more details.
|
|
|
|
When an audit backend is disabled, it will stop receiving logs immediately.
|
|
The existing logs that it did store are untouched.
|
|
|
|
## Blocked Audit Backends
|
|
|
|
If there are any audit backends enabled, Vault requires that at least
|
|
one be able to persist the log before completing a Vault request.
|
|
|
|
If you have only one audit backend enabled, and it is blocking (network
|
|
block, etc.), then Vault will be _unresponsive_. Vault _will not_ complete
|
|
any requests until the audit backend can write.
|
|
|
|
If you have more than one audit backend, then Vault will complete the request
|
|
as long as one audit backend persists the log.
|
|
|
|
Vault will not respond to requests if audit backends are blocked because
|
|
audit logs are critically important and ignoring blocked requests opens
|
|
an avenue for attack. Be absolutely certain that your audit backends cannot
|
|
block.
|