search

hashicorp / vault-lambda-extension

Mozilla Public License 2.0
138 stars 29 forks source link

Enhancement: Provide ways to Trigger Token Refresh #148

Closed aztalbot closed 2 months ago

aztalbot commented 3 months ago

I've observed an issue where an otherwise valid token is no longer usable - the service returns 403. This issue can pop up in a redundancy setup where perhaps the token is only valid in one of those vault systems and the expectation is that the client would re-authenticate when a redundant system comes online.

There is currently no way for the client (I mean the core lambda application) to force the Vault Extension to re-authenticate. Instead, the client must wait for token expiry. An enhancement to force re-authentication would allow applications to ensure they never get stuck with an unusable token, no matter how that situation arises.

I propose two additions to the Vault Extension:

  1. Accept a new Boolean environment variable VAULT_REFRESH_TOKEN_ON_FORBIDDEN. Defaults to false. If set to true, refresh the token after receiving a forbidden response (403) and retry the request. This applies to all requests.
  2. Accept a new header X-Vault-Refresh-Token in the proxy. Acceptable values are force, and retry. force will refresh the token before producing the request. retry will refresh the token if the proxied request receives a 403 Forbidden response, and then retry the same request.

Does this sound like an acceptable enhancement? If so, I'm more than happy to contribute.

aztalbot commented 3 months ago

Following up on this: I've created a PR to allow revoking a token, thus triggering re-authentication, by passing X-Vault-Token-Options: revoke in the request headers. This seemed simpler than what I proposed above.