-
Notifications
You must be signed in to change notification settings - Fork 60
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
Support "caching" token after initial login #104
Comments
EDIT: in the mentioned module, seems like it may not have worked: jhaals/ansible-vault#61 |
Hi @dsafanyuk , thanks for opening this feature request! As it happens, this is something I've been thinking about for quite a while. It's definitely not ideal to be doing logins for every retrieval. So I'll briefly say that this will be addressed in some form or another, though it may not be exactly what you had in mind. WorkaroundsFirst I'll talk about what can be done today to workaround this situation. Because the plugin supports token authentication already, if you acquire your token outside the plugin, you can (re)use the plugin with that token. One example would be using the Vault CLI to execute a The call to With those latter options, there's also the possibility of using Another workaround is using Vault Agent with auto-auth, and pointing the plugin to contact the agent rather than the Vault server directly. A recent contribution (#80) enabled this functionality via the Vault Agent can also be used with Short(-ish) Term PlansI'm still working through reorganization of the internals, but the goal is that this collection won't be just this single plugin. And the the first additional plugin(s) and/or module(s) will almost certainly be centered around doing auth only, and returning a token. That will allow selectively controlling auth, and the resulting token use and lifecycle, separately from Vault operations (and it won't require the Vault CLI/binary). What's the hold up?Moving the pieces of the existing code, most of which revolve around auth (and connections), into shared libraries so that 1) it's not duplicated around the collection, 2) it behaves consistently within the collection, and 3) each part can be tested independently without repeating tests or strongly coupling tests for different content. Long TermVarious other ideas might be possible, for example an option that allows for persisting auth after it's done, in any of the plugins (writing it to a file), or perhaps using a token helper (#91) more generally. It's too early to say for sure, but to me this sounds like a good option to have specifically on an auth plugin/module, and perhaps not on any plugin that does "integrated" auth, we'll see. I've also considered adding a vars plugin that might be better suited to consolidating vault access by managing its own auth and/or token lifecycle, while an Ansible author need only define what they need upfront, and then can reference secrets as needed as ansible vars. A lot of research and testing will be needed for this, but I'll be taking some inspiration from I'd also like to look at ways that token lifecycle could be handled, either manually or transparently, throughout an Ansible run, to account for token ttl, renewal, etc. But that too will require a decent amount of research and testing. I think that will become clearer as the other pieces fall into place. DifficultiesThere are a few things that make caching problematic, some of which have been talked about above. One thing we have to keep in mind is that tokens are secrets too, so we have to be somewhat careful about how and where they are cached, to avoid exposing them unintentionally, and critically, giving the user a lot of control over how that happens. In the case of controller side content (plugins/actions) that can be somewhat straightforward, while in modules, which execute on the remote side, there are other issues to consider, like whether a cache system only works on the target host, or whether it exfiltrates the token back to the controller; stuff like that. I'm still interested in hearing your thoughts on the above, and any other ideas you want to discuss. Thanks again! |
Hey thanks for the explanation! I can go into a bit into our scenario: We're currently using AWX(15.0.1) + custom credential types that inject the approle credentials as envvars. I can't share code but here's the tutorial we followed: link We previously did use a plain Vault Token that we retrieved by auth-ing using approle credentials. I am trying to steer away from this because we had to have a lot of automation surrounding this (renewing the token, updating the AWX credential with a fresh credential, etc.)
One solution to my specific problem was forking this collection and adding a Another option was to use # pre_task
- name: get a vault token
set_fact:
ansible_vault_token: "{{ lookup('community.hashi_vault.hashi_vault', ' auth_method=approle role_id=myroleid secret_id=mysecretid') }}"
# notice the lack of "secret=foo"
# or
- hosts: localhost
vars:
ansible_vault_token: "{{ lookup('community.hashi_vault.hashi_vault', ' auth_method=approle role_id=myroleid secret_id=mysecretid') }}"
tasks:
- name: debug
debug:
msg: "{{ lookup('hashi_vault', 'secret=secret/foo:value') }}" |
Thanks for adding some explanation! For your AWX setup (using env vars) you may want to take a look at #49 and #86 as some of the env vars you are using may be deprecated, and AWX doesn't allow the new env vars (those beginning with
If I understood this correctly, it sounds like someone manually logs into Vault with AppRole auth to retrieve a long-lived token, and that token is then used until it expires (or rather than manual, this was what all of the unwanted automatio was doing). That of course is less than ideal, as a token is meant to be ephemeral.
I may need more explanation of this, I'm not following how adding a
I think this is similar to one of the workarounds I mentioned, which is to call In your example though, with "notice the lack of secret=foo" I don't understand how that could work as the existing lookup never returns a token. Was that meant to be a feature of your fork? It would however fit the newer plugin I was mentioning which could do auth and return a token, that's exactly what I had in mind. |
correct
Our specific issue is that our Vault instance cannot replicate the token to the standby nodes fast enough. So the team that manages Vault has observed that by putting in a delay between auth/reads, it gave enough time to replicate the token across the vault cluster.
Yes, i'd love that feature! |
Oh that's interesting. Have you engaged with HashiCorp support by any chance? I am wondering if this would be considered an issue related to the cluster configuration, or if such a delay is expected to be handled on the client side, or something else. BTW you might benefit from the latest feature added, which is I suspect this would solve (or at least, workaround) that issue, as the login request would succeed, and then the failing secret read would be the request that is retried. You may need to adjust the retry parameters in terms of backoff, number of retries, perhaps even changing the HTTP status codes that are retried, to fit your particular situation, however the I'd love to know if that works for you. |
@dsafanyuk I know it's been a while but I wanted to give some updates. Although we don't have built-in caching for the login from one plugin call to another, we now have the We also have the I'm using this setup in production with (Ansible + I also want to let you know that we did in fact encounter a token replication issue in production just as you described. We did ultimately work that problem out (underlying storage performance was not up to par), but what's notable is that our entire Ansible fleet largely did not notice it, because we had it configured to perform connection retries. Because this options works at the connection level, we were not stuck in a loop of retries performing new logins; it's the subsequent requests that were retried with the same original token, so they eventually worked and all it did was slow down our Ansible runs a little and spit out some warnings. That being said, HashiCorp also introduced some new eventual consistency mitigations, and I have an open issue (#170) to see if it makes sense to implement anything like that within this collection, or in One other requested feature was support for token helpers (#91), but it does have some of the same difficulties as implementing central caching. I'd be interested to know how you're getting along with Vault and Ansible lately. |
Hey @briantist ! I actually moved from my company and we don't use Ansible/Vault at my new one :/ I do appreciate the write up; we can close this issue if you think it's prudent. |
Thanks for the quick response @dsafanyuk ! |
SUMMARY
To avoid multiple logins, it'd be great if the lookup module supported a token cache after initial login
ISSUE TYPE
COMPONENT NAME
lookup
ADDITIONAL INFORMATION
Currently, it seems for multiple
lookups
, each lookup does log in + reads from vault.Would you be open to supporting a feature that adds a token cache?
Here's an example of a now deprecated module that had this feature: https://github.com/jhaals/ansible-vault/blob/17fdb6fde3cb441bc7737770591b5ab5c79a3fe3/vault.py#L100-L108
The text was updated successfully, but these errors were encountered: