mirrors/vault
1
0
Fork 0
mirror of https://github.com/hashicorp/vault.git synced 2025-11-28 06:01:08 +01:00
Code Issues Projects Releases Wiki Activity

Documentation update: Added tuner parameters to the Sensitive information section (#12655)

Browse Source 
* added tuner parameter to doc

* reworded the text

* updated text based on feedback

* fine-tuning sentence

* changed to relative links
This commit is contained in:
Loann Le 2021-09-28 11:44:46 -07:00 committed by GitHub
parent 558ed17f72
commit c45db9d058
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
website/content/docs/audit/index.mdx
View File

@ -29,17 +29,22 @@ The audit logs contain the full request and response objects for every
interaction with Vault. The request and response can be matched utilizing a
unique identifier assigned to each request.
With a few specific exceptions, all strings (including authentication tokens and lease information) contained within requests and
responses are 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 device's hash function and salt by using the
`/sys/audit-hash` API endpoint (see the documentation for more details).
Most strings contained within requests and responses are 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 device's hash function and salt by using the `/sys/audit-hash` API endpoint (see the documentation for more details).
Note that currently only strings coming from JSON or being returned in JSON are
HMAC'd. Other data types, like integers, booleans, and so on, are passed
through in plaintext.
While most strings are hashed, Vault does make some exceptions, such as auth and secrets, and users can enable additional exceptions using the [secrets enable](/docs/commands/secrets/enable) command, and then tune it afterward.
**see also**:
[secrets tune](/docs/commands/secrets/tune)
[auth enable](/docs/commands/auth/enable)
[auth tune](/docs/commands/auth/tune)
## Enabling/Disabling Audit Devices
When a Vault server is first initialized, no auditing is enabled. Audit
@ -56,12 +61,12 @@ In the command above, we passed the "file_path" parameter to specify the path
where the audit log will be written to. Each audit device has its own
set of parameters. See the documentation to the left for more details.
~> Note: Audit device configuration is replicated to all nodes within a
cluster by default, and to performance/DR secondaries for Vault Enterprise clusters.
Before enabling an audit device, ensure that all nodes within the cluster(s)
will be able to successfully log to the audit device to avoid Vault being
blocked from serving requests.
An audit device can be limited to only within the node's cluster with the [`local`](api/system/audit#local) parameter.
~> Note: Audit device configuration is replicated to all nodes within a
cluster by default, and to performance/DR secondaries for Vault Enterprise clusters.
Before enabling an audit device, ensure that all nodes within the cluster(s)
will be able to successfully log to the audit device to avoid Vault being
blocked from serving requests.
An audit device can be limited to only within the node's cluster with the [`local`](api/system/audit#local) parameter.
When an audit device is disabled, it will stop receiving logs immediately.
The existing logs that it did store are untouched.