d1f2b101b5
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?".
42 lines
1.9 KiB
Plaintext
42 lines
1.9 KiB
Plaintext
---
|
||
layout: docs
|
||
page_title: Socket - Audit Devices
|
||
description: The "socket" audit device writes audit writes to a TCP or UDP socket.
|
||
---
|
||
|
||
# Socket Audit Device
|
||
|
||
The `socket` audit device writes to a TCP, UDP, or UNIX socket.
|
||
|
||
~> **Warning:** The loss of audit logs may occur when using the UDP socket audit type. Because UDP socket audit type is connectionless, meaning the UDP endpoint becomes unavailable, it’s possible that any number of audit logs written to it may get lost, even though the request will still succeed. Vault does not provide an indication for the loss of audit logs. Therefore, we recommend using your device in conjunction with a secondary “non-socket” audit device to ensure accuracy and to guarantee that audit logs will not be lost.
|
||
|
||
~> **Warning:** When using a TCP socket audit type, and connection loss to the socket occurs, a single audit entry may be omitted from the audit entry. The request from the TCP socket audit type will succeed despite the omission of the audit entry.
|
||
|
||
## Enabling
|
||
|
||
Enable at the default path:
|
||
|
||
```shell-session
|
||
$ vault audit enable socket
|
||
```
|
||
|
||
Supply configuration parameters via K=V pairs:
|
||
|
||
```shell-session
|
||
$ vault audit enable socket address=127.0.0.1:9090 socket_type=tcp
|
||
```
|
||
|
||
## Configuration
|
||
|
||
The `socket` audit device supports the common configuration options documented on
|
||
the [main Audit Devices page](/docs/audit#common-configuration-options), and
|
||
these device-specific options:
|
||
|
||
- `address` `(string: "")` - The socket server address to use. Example
|
||
`127.0.0.1:9090` or `/tmp/audit.sock`.
|
||
|
||
- `socket_type` `(string: "tcp")` - The socket type to use, any type compatible
|
||
with <a href="https://golang.org/pkg/net/#Dial">net.Dial</a> is acceptable. It's
|
||
important to note if TCP is used and the destination socket becomes unavailable
|
||
Vault may become unresponsive per [Blocked Audit Devices](docs/audit/#blocked-audit-devices).
|