open-vault/website/content/docs/audit/socket.mdx

42 lines
1.9 KiB
Plaintext
Raw Normal View History

2016-12-07 04:35:30 +00:00
---
layout: docs
page_title: Socket - Audit Devices
description: The "socket" audit device writes audit writes to a TCP or UDP socket.
2016-12-07 04:35:30 +00:00
---
2017-09-08 02:38:47 +00:00
# Socket Audit Device
2016-12-07 04:35:30 +00:00
2017-09-08 02:38:47 +00:00
The `socket` audit device writes to a TCP, UDP, or UNIX socket.
2016-12-07 04:35:30 +00:00
2022-05-18 15:26:25 +00:00
~> **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, its 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.
2016-12-07 04:35:30 +00:00
## Enabling
2017-09-08 02:38:47 +00:00
Enable at the default path:
2016-12-07 04:35:30 +00:00
```shell-session
2017-09-08 02:38:47 +00:00
$ vault audit enable socket
2016-12-07 04:35:30 +00:00
```
2017-09-08 02:38:47 +00:00
Supply configuration parameters via K=V pairs:
2016-12-07 04:35:30 +00:00
```shell-session
2017-09-08 02:38:47 +00:00
$ vault audit enable socket address=127.0.0.1:9090 socket_type=tcp
2016-12-07 04:35:30 +00:00
```
2017-09-08 02:38:47 +00:00
## Configuration
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 `socket` audit device supports the common configuration options documented on
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:
2017-09-08 02:38:47 +00:00
- `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
2022-05-18 15:26:25 +00:00
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](/vault/docs/audit/#blocked-audit-devices).