-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vault Agent lease cache interferes with template refresh for dynamic secrets #19684
Comments
Hi there, The Could you confirm whether or not you're sending API requests directly to Vault Agent as part of this reproduction? Alternatively, could you confirm whether or not you're still seeing this bug with the Notably, we log I think this might be another case of #16439 / #19227, which wouldn't require the cache or Thanks, |
Hi, Violet. I agree, those two issues you linked appear to have the same root-cause. Notably, I see that the author of #16439 observed that they run their Agents with
No requests are being sent to the Agent's listener. All requests are coming from the Template server's
That message is logged only when the request does not already contain a token. Requests for templates already contain a token. Every time the auto-auth system gets a fresh token, that token is sent to the template system, which then restarts all its
In my testing, toggling Agent log with
|
It makes sense that the This problem with template refreshing only happens because the Template's In fact, I suspect that we would also see this problem with an external client, since any well-behaved Vault client should be attempting to renew their own leases. If an external client were to use the Proxy with caching enabled, and authenticated via the Proxy (so the Actually, I decided to just go ahead and test this with an external client. My suspicion was correct: with only a listener and caching enabled (no templates and no auto-auth at all), an external client attempting to use |
Brain-storming some possible solutions:
|
is there any workaround? Also experiencing this behavior when trying to use persistent cache between vault init and vault agent sidecar in kubernetes environment.
|
Hi folks! Is this still an issue in newer versions of Vault? Please let me know so I can bubble it up accordingly. Thanks! |
@hsimon-hashicorp Yes, I am currently seeing this behaviour with Vault 1.15.4. |
Describe the bug
The Vault Agent template server can fail to refresh secrets before lease expiration when the Vault Agent is configured with
template
stanza using a dynamic (leased) secretcache
stanza (lease-cache enabled)use_auto_auth_token
set to eithertrue
or"force"
All requests issued by the Template server are sent via the Agent's API Proxy using the current Auto-Auth token. When
use_auto_auth_token
is enabled, the current Auto-Auth token is registered in the Lease Cache. As a result, the Lease Cache will intercept all requests made by the Template server and internally handle renewal of any leases returned to the Template server.1The Lease Cache will also intercept requests from the Template server to
v1/sys/leases/renew
and will cache these responses because the response message is interpreted as a secret due to its"lease_id"
field.2 As a result, until the Lease Cache's internal renewal loop finishes, all future renewal attempts from the Template server will be served from the cache -- even as the lease is approaching it'smax_ttl
, the Template server will be receive responses which suggest the lease is still being renewed for the entire defaultttl
(rather than the true truncated duration up to themax_ttl
). This results in the Template server waiting up tottl*2/3
seconds (the normal lease renewal period) after the lease has expired before requesting a new secret and re-rendering the template.To Reproduce
Example Agent
config.hcl
. Modify for your Vault token file location and dynamic secret API path.vault agent -log-level debug -config config.hcl
Example Agent log
From the above log, the following events are noteworthy:
LifetimeWatcher
attempts the first lease renewal and the result is cached:max_ttl
:This resulted in a 10 minutes 57.4 second period between rendering the first and second secrets, even though the original secret expired after 10 minutes.
Expected behavior
The Vault Agent should reliably re-render templates containing dynamic secrets before the existing secrets' leases expire. Based on the implementation of
LifetimeWatcher
, we should expect templates to be re-rendered at leastTTL * 0.10
seconds before themax_ttl
is reached.Environment
Footnotes
Though unrelated to this bug, this doubles the number of renewal requests sent to the Vault server, since both the Lease Cache and the Template server (via
consul-template
) are attempting to keep the lease renewed. ↩The Lease Cache will actually spawn another
LifetimeWatcher
renewal loop for thev1/sys/leases/renew
response, separate from the original secret request, so the renewal request load on the Vault server is in fact tripled. ↩The text was updated successfully, but these errors were encountered: