Running different versions of proxy and server
There is no requirement to run identical versions of Vault Proxy and Vault Server. It is safe to run different versions, however you may not be able to take advantage of all the newest features in Vault if you do not upgrade to the most recent versions of Proxy and Server. We recognize that this isn’t always possible, so we do support version mismatch as best as possible.
Proxy will write a note to its logs when it detects a mismatch between Proxy and Server. This is purely informative, intended to assist with debugging in case the mismatch is given rise to problems, e.g. because a newer Proxy version is trying to make use of functionality that doesn't exist in the Server version it's talking to. If Proxy is behaving acceptably, the message may be ignored.
This document describes the common cases. There may be occasional exceptions, which if intentional will be called out in the CHANGELOG in a CHANGES
section. If unintentional/undocumented these should be treated as bugs and reported.
Older version of proxy than server
We do not anticipate any problems stemming from continuing to run an older Proxy version after the server nodes are upgraded to a later version. Existing deployments using Proxy should not be impacted, as we don't generally make backwards-incompatible changes to Vault Server.
Auto-auth:
- new auth methods that have been introduced since Proxy was built will be unavailable
- existing auth methods should continue to function normally
Proxy:
- since Proxy simply mirrors the incoming requests, even if an incoming request uses an endpoint that didn't exist when that version of Proxy was compiled, that won't impede Proxy's ability to proxy the request
Newer version of proxy than server
It is possible that an Proxy could depend on features that don’t exist in older Server versions.
Auto-auth:
- Proxy may claim to support newer auth methods that have been introduced since Server was built, but they won't work due to Server not supporting them
- Proxy may make use of new functionality for existing auth methods that isn't available in an older Server you're using
- Generally we will try to make such a change be opt-in, or to gracefully degrade when connecting to an older Server instance, unless there's a very good reason (such as a serious security flaw being patched)
Proxy:
- since Proxy simply mirrors the incoming requests, it is unlikely that incompatibilities would surface in proxying, but new functionality may not be available
- example: When client-controlled consistency support was added to Proxy, it started looking for X-Vault-Index headers in responses, and started providing X-Vault-Index headers in proxied requests. Older Vault Enterprise servers that don't make use of these headers would ignore the new request header and not emit them either. Proxy proxying behaviour continued unchanged, unable to take advantage of the new functionality, but also not impeded in its previously existing behavior.