Support writing to Vault

[horazont]

SUMMARY

Support writing to Vault. Like vault_read, there should be a vault_write action. This is useful with secrets engines which use writes to generate data, such as PKI (generating a certificate), SSH (signing a key) etc.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

New, I guess? (Sorry, I don't really have a clue what is meant by "component" here)

ADDITIONAL INFORMATION

This is how I imagine it could look, using the SSH engine as an example:

- name: sign SSH host key
  community.hashi_vault.write:
    path: ssh/sign/rolename
    data:
      public_key: "{{ the_nodes_public_key }}"
      cert_type: host
    register: signed_key

- name: display signed key
  debug:
    msg: "my signed key is: {{ signed_key.data.signed_key }}"

[briantist]

Hi @horazont , there absolutely will be content that supports writing to Vault. At the moment I'm focusing on adding a few more read-only type things, and then shoring up the testing infrastructure and patterns before jumping into write operations. See also #162 and some of the discussion there.

[horazont]

If I understand it correctly, #162 is about specific tools for kv2. The vault_write I propose is intended to be an equivalent to the CLI tool's vault write and a counterpart to the existing read action, so as an escape hatch to deal with situations where no more specific module exists yet.

However, #162 also contains a more general point about testing. What is the estimated timeline to get the testing infrastructure in line for that and is there a more fine-grained list of tasks which would have to be resolved for that?

The challenge for us is that we'd like to use this collection within the next month or so to be able to actually write stuff into vault from ansible. For this, we can allocate a bit of time to do implementation work if necessary, including helping to improve the CI checks.

(Our fallback path would be to either use https://github.com/TerryHowe/ansible-modules-hashivault [which does seem a bit unmaintained at this point in time] or make command calls to vault [which is tricky to do right with more complex authentication regarding token handling], so we'd like to avoid that and instead do the necessary contributions here.)

[briantist]

@horazont I apologize for the delay, I though I responded to the above already!

---

If I understand it correctly, #162 is about specific tools for kv2. The vault_write I propose is intended to be an equivalent to the CLI tool's vault write and a counterpart to the existing read action, so as an escape hatch to deal with situations where no more specific module exists yet.

That is exactly how I see vault_write working as well; it's a generic available for things that are not covered (yet?) by more specific content.

However, #162 also contains a more general point about testing. What is the estimated timeline to get the testing infrastructure in line for that and is there a more fine-grained list of tasks which would have to be resolved for that?

The challenge for us is that we'd like to use this collection within the next month or so to be able to actually write stuff into vault from ansible. For this, we can allocate a bit of time to do implementation work if necessary, including helping to improve the CI checks.

I understand, thank you for the context!

I will say that I don't see this being ready for you within the next month or so, just because the last two months are quite busy for me, so the planned work I have is in progress and moving along, but slowly.

(Our fallback path would be to either use https://github.com/TerryHowe/ansible-modules-hashivault [which does seem a bit unmaintained at this point in time] or make command calls to vault [which is tricky to do right with more complex authentication regarding token handling], so we'd like to avoid that and instead do the necessary contributions here.)

I can recommend two alternative workarounds, that are similar but distinct:

1. You can maintain a (temporary) fork of community.hashi_vault, with a vault_write module and/or lookup that you might consider opening a PR with once we're ready upstream.
2. You can create vault_write (or other) modules/plugins locally (in a role, in a collection, etc.), that make use of the module utils in this collection. So you can make use of the central stuff the collection offers to keep your stuff small, and later you can abandon those for upstream content (or try to contribute them).

Notes about Option 1

You'll be able to see the tests run in your fork's GitHub, which will help somewhat in ensuring some level of alignment, for a future contribution.

You can keep the fork maintained by rebasing from upstream.

Your local setup where you need to use it might be a little annoying, having to install the collection from your fork.

Notes about Option 2

The module utils in this collection are all considered internal, so they can change anytime in a way that breaks the interface. Actually, this is still an issue with Option 1 too, but it's something to consider. I would not recommend either of these options for you for long term use for that reason.

With Option 2, you can keep this stuff committed in your repo, or maintain a separate collection internally, or whatever you like, while not affecting how your Ansible uses consume the upstream collection.

[horazont]

Alright, so plans, as usual, have been deferred here, too. Things are becoming more relevant now and I wonder if the status on your side of things has remained the same?

To be honest, I have never started an ansible module from scratch so I'm not quite sure how the necessary cross-importing for option 2 would work, but I suppose that can be figured out. That way would probably be preferable for us as that tends to be easier than trying to convince ansible to pull stuff it knows about from a non-default source.

In addition, I expect this to break more loudly when we diverge from upstream (you), because we'll notice when things break on automatic dependency updates, while we might otherwise simply not rebas our fork :).

[briantist]

The cross-importing just works, you reference the collection you want to import from (you can check the existing content here, it doesn't work only because the content is within the same collection).

I still absolutely plan to implement vault_write. Personal, work, and side projects are taking a lot of my time at the moment.

In this collection, there's two new plugins on the way #216 and #213 (these wouldn't have been higher on my list, but I was prioritizing contributors/requests), vault_write is probably next on my list.

[briantist]

Hey @horazont , just wanted to let you know that I started implementing this in #223 in case you want to follow along.

[briantist]

@horazont #223 is ready for review if you'd like to take a look.