feat: Support Configuration of Vault Proxy
ChrisJBurns opened this issue · comments
As release 1.14 has deprecated Vault Agent API proxy support we want to be able to configure the new Vault Proxy using the Helm Chart. Currently I cannot see any mentioned of proxy in the Values file leading me to believe it's currently not possible to configure yet.
To clarify, is this a request for improved support using the proxy within the sidecars that Agent injector creates (i.e. one proxy per pod), or for deploying the proxy as a separate deployment (i.e. one proxy per cluster)? It sounds like the latter?
Hi @tomhjp, good question. I'm not entirely sure which things happens at the moment as the lines between Vault Proxy and Vault Agent API Proxy seem somewhat blurred a bit. To double check, the sidecars that the Agent Injector creates, is this using any now deprecated capability? Or is it already using Vault Proxy?
Vault Proxy (new in 1.14.0) and Vault Agent API Proxy (deprecated but unchanged as of 1.14.0) are currently the same thing. The former is the new home for that functionality and may diverge from the latter in future releases, and the latter is staying in place for a while for backwards compatibility (although I'm not sure on timelines, so I can't comment on what "a while" translates to).
It's possible to use the Agent Injector to create an Agent sidecar running the Agent API Proxy, but injector mostly focuses on the templating use case.
What kind of pattern would you like to use the Vault Proxy for? Would love to hear more about your requirements, and I've also forwarded this issue onto the team that owns Vault Proxy.
@tomhjp Ahh if they're the same thing at the moment, then the current Helm Chart should be fine until there's a divergence in the underlying functionality within Vault for the API Proxy and the new Vault Proxy.
For my use case we are running the Vault Agent sidecar (with the Init container also) for two use cases:
-
- To act as a proxy for our Java applications that use the Spring Cloud Vault library with Agent authentication. The secrets are sourced at start time and all proxying and authn/z is done via the agent sidecar (which is incredibly handy).
-
- We use the Agent and the Init Container to inject secrets (based on annotations via the templating) into the main application container. This is for applications that do not have a Vault library that we can utilise like in use case 1.
For us, we were just double checking whether there was any change in the Helm Chart that we needed to make in order to accommodate the change from 1.13.2 to 1.14.0, but as you've said, it should be the same for now and we should keep an eye out for future minor releases to ensure we're aware of when the divergence is.
I guess the only thing to note for the Vault Helm Chart is just to ensure that this Chart understands when the divergence happens, and to ensure that we can set the correct values to ensure things continue working.
Thanks for the information! That's super helpful context. We'll definitely keep this kind of use-case in mind as we make changes. The Vault Proxy roadmap is still forming, and as we get a clearer view of how that shapes up down the road we'll get a better idea of how vault-helm and friends should leverage it.
We're very cognisant of the impact breaking changes have, so if we do plan any we'll endeavour to share them ahead of time as well as making them nice and clear in the changes section of the Vault and vault-helm changelogs. But I'm hoping we'll be able to maintain compatibility from a vault-helm perspective if we ever do need to switch its usage between the two.
I think that means there's nothing to implement (yet) for this feature? I'll close it for now, but feel free to re-open if I've missed something, and thanks again for sharing your usage - it's super helpful input for our roadmap.
Yep sounds great, thanks @tomhjp ! I think this issue will provide some context for those who are also worried about the deprecation which is good!