Clarify more documentation on audit logging (#17957)

Thanks to Khai Tran for identifying that syslogging has a lower limit
on message size and sometimes large CRLs can hit that limit.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
This commit is contained in:
Alexander Scheel 2022-11-16 09:21:29 -05:00 committed by GitHub
parent f3c9e98fd5
commit ab395f2c79
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 0 deletions

View File

@ -385,6 +385,21 @@ Because Vault HMACs audit string keys by default, it is necessary to tune
PKI secrets mounts to get an accurate view of issuance that is occurring under
this mount.
~> Note: Depending on usage of Vault, CRLs (and rarely, CA chains) can grow to
be rather large. We don't recommend un-HMACing the `crl` field for this
reason, but note that the recommendations below suggest to un-HMAC the
`certificate` response parameter, which the CRL can be served in via
the `/pki/cert/crl` API endpoint. Additionally, the `http_raw_body` can
be used to return CRL both in PEM and raw binary DER form, so it is
suggested not to un-HMAC that field to not corrupt the log format.<br><br>
If this is done with only a [syslog](/docs/audit/syslog) audit device,
Vault can deny requests (with an opaque `500 Internal Error` message)
after the action has been performed on the server, because it was
unable to log the message.<br><br>
The suggested workaround is to either leave the `certificate` and `crl`
response fields HMACed and/or to also enable the [`file`](/docs/audit/file)
audit log type.
Some suggested keys to un-HMAC for requests are as follows:
- `csr` - the requested CSR to sign,