-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add support for HashiCorp Vault JWT auth #1213
Add support for HashiCorp Vault JWT auth #1213
Conversation
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 submitting this @erikgb !
My comments are mostly the same as on the original PR, in that we shouldn't rebrand a specific auth method as something more generic, based on the current implementation. But since then we have a generic JWT/OIDC method to use in HVAC. See my inline comments and the original PR.
@felixfontein @briantist Thank you for your comments and suggestions. My first goal was to rebase the original commits, so I know I am not done! 😄 I will look through your feedback and modify accordingly. And then ping you for another review. |
Sounds great! Thanks again for picking this up @erikgb |
@briantist @felixfontein I think I am ready for another review! Please note that I haven't programmed a lot of Python, so please excuse me if doing stupid mistakes! 😉 Trying to learn something new every day! One thing I am wondering about: The hvac documentation states that the |
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.
This needs a changelog fragment. Everything else I can't really judge.
@felixfontein Thanks, I've added a changelog fragment. I would also like to add some tests, but I am not sure how to set it up? I can see that there are a few tests for this lookup plugin, but features seems untested.... |
Thank you very much for considering tests! It may be that this is the case for JWT also, but you may be able to get some inspiration from the PR that added JWT to HVAC, since it seems some tests were implemented there: https://github.com/hvac/hvac/pull/613/files
As far as I can tell, that's enabling the authentication method in the vault server, so not something we'd do in this plugin (as it's read-only and doesn't modify the state of Vault). |
Argh, of course. 😕 I forgot for a moment that hvac is a complete HashiCorp Vault API.... |
You and me both, when you linked that I was really intrigued because I didn't remember having to enable any methods, took a little while to figure it out haha 😅 |
@briantist We really need some tests on this new feature! Any chance that you, or some of the others watching this PR can help me get started? 😄 |
I don't use JWT auth myself, so I have very little familiarity with it. But I can help point you in the right direction on how the existing tests work, if you want to take a look at those and see if you have any questions. It also seems like the person who implemented the JWT auth method in HVAC had some similar concerns about how to write tests for it and there may be some good stuff there as far as how we might set up something to test it within CI: https://github.com/hvac/hvac/pull/613/files Tests are implemented as ansible roles, and you can see the tests for this plugin here: https://github.com/ansible-collections/community.general/tree/main/tests/integration/targets/lookup_hashi_vault |
245fbe9
to
eac72df
Compare
register: test_wrong_cred | ||
ignore_errors: true | ||
|
||
# FIXME: Somehow this test is failing. The role is getting access to secret3 - even if the policy explicitly denies it. |
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.
I'm going to try to pull this down and see if I can figure anything out with the tests locally.
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.
And what a job! Great work @briantist! I just wished you did it sooner! 😉 Now ALL tests are green. In addition to following up on the registered hvac issue, I think we should improve our test setup (in another PR). We have to make sure no additional working hours are wasted on a "self-shot" test setup. I understand why Vault is booted in dev-mode, but I think we should have a look at the -dev-no-store-token
option when starting the Vault server in dev-mode. And include the returned root-token in the vault_cmd variable. At least I think that could work....
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.
We're planning to move this plugin to its own collection very soon, which will be a good place to improve testing. Especially since then the plugin won't be limited by the community.general test setup, but you can change the testing environment in whatever way you please.
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.
Sorry took a while before I could find the time. Running these tests locally is kind of a pain because it's a custom/runme.sh
type of test apparently. Just another thing we can hopefully improve by moving the plugin. Good idea on the -dev-no-store-token
option, thanks for that! I hope you'll consider more contributions in the future :)
I don't use JWT/OIDC so I'm a little unfamiliar. If the methods are implemented the same in HVAC except the difference being the mount/path, what makes OIDC more difficult to test? Apologies if this is a basic question. Overall this is looking great @erikgb , I want to thank you once again for the effort here especially with regard to testing. |
Even if the methods are the same in hvac (and Vault), OIDC requires a server to be set up. So it is very hard to integration test - as noted in hvac/hvac#613 (comment). You need an OIDC provider.... |
Thank you, I see the issue now looking over the other PR. I think I'm on the side of keeping OIDC and acknowledging that we aren't testing it (similar to AWS IAM auth). I'm going to start keeping track of things like that that don't have coverage to document why, or what the lift is, etc. But I think we're better off including it. Thank you! |
eac72df
to
279a58e
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.
I think I figured out the problem with the test. It's a good thing we didn't merge without it, it was literally the only test catching a critical error!
The problem comes from this login method not behaving like the others in HVAC. The others automatically set the token property of the client object when doing a login; this one doesn't. I submitted an issue about it: hvac/hvac#644
The reason this was so difficult to realize is that in CI we run vault server in dev mode. This really simplifies setting it up, avoiding the need for initializing and unsealing, and automatically authenticating all local requests with the root token.
When we test auth methods we're usually using the token retrieved by that login.
But because this auth method doesn't do that, all the requests to vault ended up using the original token the HVAC client inherited, which was the root token, and that's why the request to read the secret worked,
In a realworld scenario, it likely would have failed on reading the secret even when then auth worked; or worse it may have inherited some other token.
In #23 I fixed a bug where this happened on some failed auth, and it read your local client token, but it didn't fix this scenario because the token didn't come from manual action.
I need to look into how this token gets inherited because as far as I can tell it's not in an env var or file. The fix might actually be to force a .logout()
on our HVAC client object before we do anything, so that it doesn't pull in something unexpected ever. It would have caught this sooner, as all the other reads would have failed too.
But anyway, that's another PR.
Looking at the code more closely, and the examples in HVAC, it doesn't look like our OIDC method would work, as it seems th correct method is With the uncertainty around that and the fact that we can't test it, I think I'm more comfortable reversing course and removing it from this PR. Does that make sense to you @erikgb ? If you are able to test the plugin locally (outside of CI) with OIDC, let me know, that would give me more confidence in including it. If not, no worries at all; let's remove it from this and it can be implemented another time (sorry, I know it was my suggestion to include it; I think I was mistaken about how similar they are). |
I do agree, and I will remove the OIDC auth from this PR now. As I am not a administrator on our Vault installation, nor having access to a running OIDC provider, I do not have a simple way of verifying that it works.... And ideally this should be possible to set up in CI - it is just that I do not have to do it now. 😄 |
Co-authored-by: Brian Scholer <[email protected]>
7a260b5
to
9147003
Compare
@felixfontein I see that a single test seems "flaky". How can we trigger a new CI Shippable build? |
You can add a comment with |
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.
Looking good, thanks for sticking with this through the ups and downs.
Also it got lost in the main change but I want to thank you for the docstring / description updates too. Cheers!
* Add support for Hashicorp Vault JWT auth * Add support for HashiCorp Vault JWT auth (continued) Co-authored-by: Brian Scholer <[email protected]> Co-authored-by: Mike Brancato <[email protected]> Co-authored-by: Brian Scholer <[email protected]> (cherry picked from commit 64c6f20)
@mbrancato @erikgb thanks a lot for working on this! |
* Add support for Hashicorp Vault JWT auth * Add support for HashiCorp Vault JWT auth (continued) Co-authored-by: Brian Scholer <[email protected]> Co-authored-by: Mike Brancato <[email protected]> Co-authored-by: Brian Scholer <[email protected]> (cherry picked from commit 64c6f20) Co-authored-by: Erik Godding Boye <[email protected]>
@felixfontein Thanks! Maybe a noob question: When will this feature be available in an Ansible installation? |
@erikgb it will be included in community.general 1.3.0, to be released by the end of this month (probably mid next week or so), and that will get included in the next Ansible 2.10 release. These happen ~every three weeks, so one should be released next week as well. My aim would be that c.g 1.3.0 is included in it. So end of next week is a good estimate ;) |
This PR is based on the work by @mbrancato in #154. The original pull request needs rebase, and there has been no feedback from @mbrancato since the PR was submitted in April 2020.
SUMMARY
This adds generic JWT/OIDC authentication support for the HashiCorp Vault lookup plugin. The JWT and OIDC auth only differ in the default path their methods will use. I.e., v1/auth/jwt versus v1/auth/oidc.
ISSUE TYPE
COMPONENT NAME
hashi_vault
ADDITIONAL INFORMATION
The generic JWT auth API is used by the:
JWT auth - https://www.vaultproject.io/api-docs/auth/jwt#jwt-login
GCP auth - https://www.vaultproject.io/api-docs/auth/gcp#login
Kubernetes auth - https://www.vaultproject.io/api-docs/auth/kubernetes#login
even Azure and others...