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
Implement support for Vault KV v2 backends #6115
Conversation
abb7cd7
to
8950d7d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks for picking this up!
It's unfortunate that we have to carry over so much internal code from Vault, but I get it, not sure what else to do there besides requesting upstream API changes.
There's a part of the code that mutates the client that I'm not sure will be safe though.
e9dc5d6
to
1d264fb
Compare
1d264fb
to
e91ae2f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for waiting - getting back to this now that v6.7 is out!
How would you feel about adding tests for this? Originally the API client was meant to be a thin layer that can be faked out for tests, but now it's getting a little thick. 🤔 There aren't currently tests for the API client, but they could probably be added by faking out the API endpoint using ghttp.NewServer
.
I think adding tests are a solid idea as more complexity gets added - though with it being holiday season my time is a bit limited. I'll see what I can do in the meantime but it may have to sit for a while on my end. |
aaef5e0
to
503fa1c
Compare
As addressed in this issue (i.e. concourse#2374) we would like support for Vault's KV version 2 backends to enable versioning and support default deployments of new vault instances. This implements a backwards compatible change to detect kv2 backends and resolve the paths accordingly. Tested with all gingko + testflight cases. concourse#2374 Signed-off-by: David Dobmeier <david.dobmeier@dcsg.com>
Signed-off-by: David Dobmeier <david.dobmeier@dcsg.com>
This adds support for testing the api_client for vault kv1 and kv2 support. It leverages the ghttp library handlers for this and the behavior of the AppendHandlers is a bit awkward due to the fact that each handler is only used once in a specific order. If there is a better way of registering a route or handler to clean this up id be happy to refactor a bit. Signed-off-by: David Dobmeier <david.dobmeier@dcsg.com>
…future Signed-off-by: David Dobmeier <david.dobmeier@dcsg.com>
503fa1c
to
94dbbaf
Compare
Signed-off-by: David Dobmeier <david.dobmeier@dcsg.com>
@vito Been a little while, finally got some time and finished writing tests using ghttp for both KV2 and KV1 vault apis to test the api_client. The way the ghttp handlers work make it a bit awkward and verbose as the requests much match the order of the handlers but everything seems to be functioning as expected after bringing my changes up to date with master. |
@daviddob Awesome, thanks for circling back to this! Just resolved a tiny conflict, commencing review now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and verified that the tests fail if the v2 support is removed. Left some nitpicky suggestions. I would have just merged and touched them up myself but it looks like some small changes need to be made since NewAPIClient
changed on master
recently. (I suggested changes for them.)
Once those NewAPIClient
calls are fixed up I'm happy to merge this as-is.
Used RouteToHandler to clean up all the mount api calls. Signed-off-by: David Dobmeier <david.dobmeier@dcsg.com>
Updated as per your feedback - should be good to go. Thanks @vito! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm - thanks!
After #6115 was merged, all the Bosh Topgun tests exercising Vault started failing. This is not due to the Vault integration being broken (well, not really) - Bosh topgun is just using such an old (custom) version of Vault that is no longer compatible I gather. Since we're going to end up replacing all these tests shortly with a new test suite (introduced in #6479), let's just skip these Vault tests for now Signed-off-by: Aidan Oldershaw <aoldershaw@pivotal.io>
Changes proposed by this PR:
Enables support for Vault's KV version 2 backends to enable versioning
and support default deployments of new vault instances. This implements a backwards
compatible change to detect kv2 backends and resolve the paths accordingly.
While RFC #39 was proposed to take this on it appears to still propose the use of a
vault
type. As such hopefully this is not considered aquick-fix
antipattern andcan be used to improve the credential-manager var sources as well.
Tested with all gingko + testflight cases.
Fixes #2374
Notes to reviewer:
Leverages the existing vault test suite as the changes are made to the underlying api client.
Release Note
Contributor Checklist
Reviewer Checklist
BOSH and
Helm packaging; otherwise, ignored for
the integration
tests
(for example, if they are Garden configs that are not displayed in the
--help
text).