From b2c6e68f51f865453c459e676539a8a4be4aca93 Mon Sep 17 00:00:00 2001 From: Violet Hynes Date: Tue, 17 Sep 2024 19:22:34 +0000 Subject: [PATCH] backport of commit e17fc068246b20c1559984cd902e7ed149fd1598 --- .../proxy/caching/static-secret-caching.mdx | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/website/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx b/website/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx index 1af6c0a2d304..c080c3da9f94 100644 --- a/website/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx +++ b/website/content/docs/agent-and-proxy/proxy/caching/static-secret-caching.mdx @@ -90,6 +90,16 @@ request to Vault but caches the response before forwarding it to the client. If that client makes subsequent `GET` requests for the same secret, Vault Proxy serves the cached response rather than forwarding the request to Vault. + + + Vault Proxy does not cache any non-KV API responses. While KV secrets can be retrieved even if + Vault is unavailable, other requests cannot be served. As a result, using the `vault kv` + CLI command, which sends a request to `/sys/internal/ui/mounts` before the KV `GET` request, + will require a real request to Vault and cannot be served entirely from the cache or + when Vault is unavailable (you can use `vault read` instead). + + + Similarly, when a token requests access to a KV secret, it must complete a success `GET` request. If the request is successful, Proxy caches the fact that the token was successful in addition to the result. Subsequent requests by the