new content request - create token / orphan token

[emper0r]

SUMMARY

ISSUE TYPE

• How could be possible create a token and/or orphan token with this module???
  according to the doc https://www.vaultproject.io/docs/concepts/tokens#token-hierarchies-and-orphan-tokens
  create a token do a POST using write function into endpoint and lookup just do GET.
  in this case isn't "write" a data .... we are asking to Vault to give us a token made by itself so would be "like a GET method" but... API for this need a POST.

COMPONENT NAME

hashi_vault_lookup

ANSIBLE VERSION

4.3.0

COLLECTION VERSION

1.1.3 (using today)
2.2.0 (test it)

CONFIGURATION

not exist.... now we are doing workaround using API with URI module

- name: main | Create token
  ansible.builtin.uri:
    headers:
      X-Vault-Token: "{{ lookup('env', 'VAULT_TOKEN') }}"
    url: "{{ env_vault_addr }}/v1/auth/token/create-orphan"
    method: POST
    body_format: json
    status_code: 200
    return_content: true

OS / ENVIRONMENT

STEPS TO REPRODUCE

EXPECTED RESULTS

Concept or an idea about it

new_orphan_token: "{{ lookup('community.hashi_vault.hashi_vault', token="new'', token_type=" ( periodic | orphan ), path="auth/token/create-orphan", ..... ) }}"

ACTUAL RESULTS

[briantist]

Hi @emper0r , the latest released version of community.hashi_vault, ver 2.2.0, contains a lookup plugin and a module called vault_login:

• lookup: https://docs.ansible.com/ansible/devel/collections/community/hashi_vault/vault_login_lookup.html
• module: https://docs.ansible.com/ansible/devel/collections/community/hashi_vault/vault_login_lookup.html

However these don't seem to do what you'd like, which is to use an existing token (authorization) to then create a new (possibly orphaned) token.

I do plan to add that capability in the collection, along with many other capabilities, but I do not have a timeline just yet.

I do like to respond to user requests when possible though, so because you requested it, I may implement something sooner than expected; I will be sure to update this issue with any news.

[emper0r]

In fact this is to create a particular token to can use for a service ... in any case if you can develop a simple patch we can test it (like beta-tester) because we are developing right now to automatize our vault production using all configuration with ansible of course so your module lookup would be very usefull right now.
maybe using --request POST could be get more field about those endpoint when vault is a "write" but for us human is a "read" action and solve many use cases
thanks again...

[emper0r]

if would be helpfully for you this is an old doc about a similar module
https://terryhowe.github.io/ansible-modules-hashivault/modules/hashivault_token_create_module.html

[briantist]

In fact this is to create a particular token to can use for a service ... in any case if you can develop a simple patch we can test it (like beta-tester) because we are developing right now to automatize our vault production using all configuration with ansible of course so your module lookup would be very usefull right now.

Thank you, I will certainly reach out, additional testing is always helpful.

maybe using --request POST could be get more field about those endpoint when vault is a "write" but for us human is a "read" action and solve many use cases thanks again...

I'm not completely sure what you mean here, but I will guess a little bit. Mostly in this collection we are not concerned so directly with HTTP verbs like POST or GET, because we use the hvac library for all of our calls, so our interactions are abstracted.

But I think I kind of understand what you mean more generally: in Vault there are many operations that we (human side) think of as a "read", but it requires a "write" in Vault. This includes things like, creating a token, a new secret ID for an approle, etc. This affects how we name or treat the Ansible plugins.

One example is that we do not have a generic vault_write plugin or module yet (but there will be one soon!). Making a lookup plugin for vault_write seems a little bit strange because we don't think of lookup plugins as being for writes, but in the context of Vault it does make sense sometimes, because certain information you want to retrieve from Vault, can only be gotten with a "write" operation, even though it is treated as a "read" conceptually when implementing a process.

A generic write plugin will, as you said, solve many use cases by being a sort of all-purpose write, similar to what vault_read is for reads.

But I still want to keep creating more purposeful plugins too, because they will be able to take more specific parameters, do better verification and error handling, have better semantics for the specific operation, etc. So both will be a reality!

if would be helpfully for you this is an old doc about a similar module but repository dosen't exist https://terryhowe.github.io/ansible-modules-hashivault/modules/hashivault_token_create_module.html

Thank you, I appreciate that. In fact, within our integration tests, we already need to create tokens, so we have an internal only module to create tokens. The internal modules are very lean, since they are meant to do very specific things, but this might give you an idea of how simple this could be:
https://github.com/ansible-collections/community.hashi_vault/blob/main/tests/integration/targets/setup_vault_test_plugins/library/vault_ci_token_create.py

[briantist]

@emper0r have a look at #213 when you can. It's not complete yet, so I'd ask that you wait to do a formal/in-depth review until it's taken out of draft mode, but if you want to take an early look at the code and documentation, go for it!

I don't expect the functionality to change much from the way it is now, but after writing tests I usually find something or other that needs updating, so there might be differences in the final product.

[emper0r]

Hi @briantist i saw the doc seams ok for me. we wait until be ready. thanks again

[briantist]

@emper0r I am ready to merge #213 , would you like to have a look first?

[emper0r]

@briantist good!..thanks for all.

[briantist]

@emper0r this is now released in 2.3.0, thanks for requesting and reviewing!