Allow token helpers to be used for the `hashi_vault` command about community.hashi_vault

[briantist]

Thanks @eqrx ! As of 1.4.0 we have the first new content in the collection, including the first module. I do expect soon that we'll have vault_login or something similar that can be used to authenticate and return a token, so that may be useful to you, although they won't quite use the helper system. I will still keep these things in mind. I'll also reopen this, both to keep it for continued tracking, and also so that anyone else who has the same idea can more easily find it.

Thanks again for opening it!

[briantist]

Hi @eqrx , thanks for submitting!

Part of the difficulty in implementing this for the moment will be that, at the moment, the plugin always assumes it has to authenticate. To properly support the helper, it has to be able to auth, store the token, and retrieve the token to re-use. But the challenge is that the helper design doesn't have any provision for storing metadata about the token itself, so there's no way to know before using it (or rather without a roundtrip) whether the token is valid. Retrying auth on failure isn't always the right behavior either. The Vault CLI doesn't have this issue as auth (login) commands are issued explicitly.

If we're talking about support get only for the helper, for use with the token auth method, it's a bit more feasible (presumably you'd be doing a vault login outside of Ansible, then running Ansible with the assumption that the token will be valid for the lifetime for the play. But it feels somewhat incomplete.

One other thing is that we're looking to expand the plugins available in this collection, while keeping the common stuff like auth central so that it works the same across all. So it'll take some thought about how a helper interface would be implemented.

But I do like the idea of being able to support that, just need to think about how it would best within the (future) ecosystem. I had been thinking about options for token persistence within Ansible already, it's somewhat tricky, but I'll surely keep helpers in mind during that planning and experimentation.

One of the things planned is a plugin (and module!) just for doing auth against Vault; that might be a good place to put helper implementation; where it wouldn't be shared with the rest of the plugins, but it'll be highly dependent on the intended use case. For example, the sample helper script shown in the Vault docs relies on an environment variable being set, independent of the data sent into the script (so it doesn't even work correctly with the Vault CLI in all cases, like if you use -address= to set your Vault address instead of the environment, there's no way for the helper script to know it.

---

I would love to know more about your specific token helper, what it does, whether it relies on outside information, what problem it solves for you, etc.

---

Also I'm not sure which workaround(s) you're using right now but I'll post some possible ones.

Outside Ansible the easiest is probably

ANSIBLE_HASHI_VAULT_TOKEN=$(/path/helper get) ansible-playbook playbook.yml

Within, you can use the pipe lookup within your lookup calls:

- debug:
    msg: "{{ lookup('community.hashi_vault.hashi_vault', 'secret/data/pwd', token=lookup('pipe', '/path/helper get')) }}"

With #86 (note: not released as of this writing, it'll be in 1.2.0) you could do this a little more cleanly with an Ansible var within set_fact:

- set_fact:
    ansible_hashi_vault_token: "{{ lookup('pipe', '/path/helper get') }}"

- debug:
    msg: "{{ lookup('community.hashi_vault.hashi_vault', 'secret/data/pwd') }}"

Looking forward to your thoughts!

[eqrx]

Wow, it really took me some time to respond here @briantist , please take my apologies. I am using the "Within" workaround you posted and I am very happy with that. Thank you very much for the detailed explaination!

Closing this issue since it resolved my problem but please feel free to reopen if you use this issue for tracking or smt.