docs: clarify json types and workaround (#17318)

* docs: clarify json types and workaround

* Apply suggestions from code review

Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>

Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
This commit is contained in:
mickael-hc 2022-09-27 15:35:41 -04:00 committed by GitHub
parent 826b20c1da
commit ddf8010342
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -32,9 +32,10 @@ unique identifier assigned to each request.
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
~>** Note:** Currently, only strings that come from JSON or returned in JSON are
HMAC'd. Other data types, like integers, booleans, and so on, are passed
through in plaintext.
through in plaintext. We recommend that all sensitive data be provided as string values
inside all JSON sent to Vault (i.e., that integer values are provided in quotes).
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.