community.hashi_vault
community.hashi_vault copied to clipboard
ansible-collections
hashi_vault mTLS support
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.
Files identified in the description: None
If these files are inaccurate, please update the component name section of the description or use the !component bot command.
Files identified in the description:
If these files are inaccurate, please update the component name section of the description or use the !component bot command.
It may be more correct to name parameters as client_key and client_cert,
similar to ansible.builtin.uri.
@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 https://github.com/ansible-collections/community.hashi_vault/issues/28
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?
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.
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!
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.