Allow using the vault_kv2_get module/lookup without throwing an exception for missing paths

[DerEnderKeks]

SUMMARY

I'd like to have the ability to use the vault_kv2_get module/lookup to fetch a value without an exception being thrown when the secret is non-existent, without having to do something like a string match on the error and setting failed_when: false.

Something like a ignore_missing parameter would work. The result should contain something to determine that the secret was missing.

(I want to get an existing secret or generate a new one when it's missing.)

This might be related to #312.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

vault_kv2_get

ADDITIONAL INFORMATION

[briantist]

Hello @DerEnderKeks , #312 is specifically about retrieving a deleted version of an existing secret, but it sounds like you would like to be able to ignore a secret that's completely missing, is that correct?

If you're more interested in determining that the secret was missing, then I would recommend using the existing module with failed_when or ignore_errors, or using the lookup with errors='ignore' (or errors='warn') and checking for an empty data result.

Note that there is no guarantee that the secret is actually missing, because if you don't have permission to read the path, Vault will respond with a 404 even if the secret exists.

If your ultimate goal is something more like "give me the value of the secret or create it if it doesn't exist" then first have a look at this discussion, where someone else is looking for the same thing:

• Option to transparently Write on read if no secret exists #319

I went over a few of the difficulties there. The poster has also added some code of their own, though it's not something we can support in this collection.

I may consider adding this functionality if enough people request it, or may consider a PR for it, but I think I would only accept it as a module and not as a lookup, because in general we really want to be avoiding writes in lookups in most cases.

If I were implementing it, I may seek to implement it as an action plugin that uses the existing modules behind the scenes, rather than as a full independent module, but not entirely sure at this time.

[DerEnderKeks]

Yes, I want to ignore errors when a secret is missing entirely, but the linked discussion is basically what I'd rather need.
My current solution is this for now, but I dislike the string comparison:

community.hashi_vault.vault_kv2_get: {...}
register: _secret
failed_when: _secret.exception is defined and not _secret.msg.startswith('Invalid or missing path')

A specific module that either reads a secret or creates a new one if missing would be perfect, something like vault_kv2_get_or_write.

The problem, whether a secret is missing or the token just lacks the capabilities to read it, could probably be solved using the /sys/capabilities-self endpoint.

[briantist]

Interesting, I never realized the existence of that exception field, just dug through some of the ansible code to see that! If looks like that field will only exist in debug mode or when verbosity is 3 or higher though. I would recommend changing it to _secret is failed and not ....

I'm still not sure how I feel about a dedicated module for this, but if someone wants to contribute it, I'll consider it. For you or anyone reading, if that's the case, please open an issue or discussion first (or use this one if it's still open) to discuss that ahead of time.

In any case, I personally think what you're doing is mostly fine, and it's pretty clear what's happening, but I do agree the string matching is somewhat brittle.

---

I think what I might look to do more broadly, is to maybe introduce a collection-wide convention for including the type (name) of exception in a dedicated field called something like exception_info. Maybe I'd make that a dict where it has name (the name of the class only like InvalidPath) and type that's the full name like hvac.exceptions.InvalidPath, but I have to see how feasible it is to get that info.

It would still be a string comparison, but it should be relatively stable, unlike a human-focused message.

For your example, it might look like this:

community.hashi_vault.vault_kv2_get: {...}
register: _secret
failed_when: _secret.exception_type.name == 'InvalidPath'