hashi_vault mTLS support

[levonet]

SUMMARY

Currently, the lookup plugin does not support authorization for a client certificate.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

community.general/plugins/lookup/hashi_vault.py

ADDITIONAL INFORMATION

- debug:
    msg: "{{ lookup('community.general.hashi_vault', 'secret/hola:value', url='https://myvault:8200', token=vault_token,
      ca_cert='/cert/path/ca.crt', tls_key='/cert/path/client.key', tls_cert='/cert/path/client.crt') }}"

It may make sense to add an alias tls_ca for ca_cert to use parameters with names appropriate to the sense.

[levonet]

It may be more correct to name parameters as client_key and client_cert,
similar to ansible.builtin.uri.

[gundalow]

@levonet Thank you for this feature request, and thinking about consistency with ansible-builtin.uri

FYI we now have a dedicated collection called community.hash_vault, so I've moved this issue #28

[briantist]

Hi @levonet , thanks and welcome! Could you clarify whether you're looking for support for client cert verification on the vault server listener, or the cert auth method?

[levonet]

I want to use something like client cert verification. I didn't quite understand how tls_client_ca_file works.
The signed certificate and CA can be defined via tls_cert_file. And key in tls_key_file.

But on the ansible side, I want to use a client key and a temporary certificate signed by CA.

[briantist]

tls_client_ca is the CA cert used to determine is a presented client cert is valid.

tls_cert_file and tls_key_file are not related to client cert validation, I think. They are the keypair used to serve vault over TLS (so tls_cert_file is the cert you'd see in your browser if you connected to the vault server, for example).

I think (based on the description of tls_require_and_verify_client_cert) that if you don't provide tls_client_ca_file in your configuration, then client certs are validated against the CAs available on the server's system.

This plugin wouldn't be able to take and pass in a CA for client cert validation, as it's just making a request to a running vault server, not changing that server's TCP listener configuration. And it wouldn't be much of a validation if servers let you tell them which CAs to use to validate the certs you send in, as then the client can make every cert valid :)

The current ca_cert parameter is used for verifying that the certificate presented by the vault server is valid.

---

So as far as I can tell this request is not too difficult to implement, but the tests will be a bit tricky to fit into the existing test suite imo.

If I were to implement this it would be post 1.0.0 release of this collection, and probably after some considerable refactoring of the tests to make implementation easier. It's definitely something I think we should support.

If you'd like to implement please feel free to put up a PR!

[levonet]

I want to do two-way authentication, like in Docker for example.
Thanks for the hint about tls_require_and_verify_client_cert.

This plugin wouldn't be able to take and pass in a CA for client cert validation, as it's just making a request to a running vault server, not changing that server's TCP listener configuration. And it wouldn't be much of a validation if servers let you tell them which CAs to use to validate the certs you send in, as then the client can make every cert valid :)

I understand that. But without CA private key, it is not possible to sign a client certificate. mTLS is here only at the channel level and should not contact the service directly.
I want to try this design with mTLS because in my architecture it is much easier to automatically create a temporary client certificate than to manage access tokens manually.

If you'd like to implement please feel free to put up a PR!
Maybe we will do it ourselves.