proxmox*: allow passing CA cert path to validate_certs option
Opened this issue · 3 comments
Summary
Currently the various community.general.proxmox*
plugins have two documented options for dealing with TLS certs: using the PVE-generated certs and ignoring that they aren't trusted (the default), or installing trusted certs on the nodes and setting validate_certs
to true
. Proxmox itself supports a third option: importing PVE's root CA certificate into the local trusted certs inventory and using it to verify the PVE-generated certs. Taking this approach with the community.general.proxmox*
plugins is made complicated by the fact that the Python requests
module (which is what proxmoxer
uses to handle the actual API calls) doesn't rely on the system's ca-certificates
bundle (i.e. simply importing PVE's root CA cert into the system bundle won't make requests
trust it).
My current work-around is to set environment: REQUESTS_CA_BUNDLE: "/path/to/pve-root-ca.pem"
(in addition to verify_certs: true
) for all community.general.proxmox*
tasks, but there might be a cleaner way using the validate_certs
option itself. Currently, the value for this option is simply passed verbatim to proxmoxer
's verify_ssl
parameter, and proxmoxer
in turn simply passes verify_ssl
to requests
's verify
parameter, which accepts a path to a CA cert in addition to the usual boolean values. In theory this means it should be possible to provide community.general.proxmox*
's verify_certs
with the path to a CA cert and have requests
verify any HTTPS connections against the specified cert (and with minimal code changes to boot).
Issue Type
Feature Idea
Component Name
proxmox
Additional Information
- name: Current way to verify HTTPS connections against PVE's root CA
community.general.proxmox_kvm:
api_user: "{{ proxmox_api_user }}"
api_token_id: "{{ proxmox_api_token_id }}"
api_token_secret: "{{ proxmox_api_token_secret }}"
api_host: "{{ proxmox_api_host }}"
name: "{{ hostvars[inventory_hostname]['inventory_hostname_short'] }}"
state: started
validate_certs: true
delegate_to: localhost
environment: "{{ omit if proxmox_ca_path is not defined else {'REQUESTS_CA_BUNDLE': proxmox_ca_path} }}"
- name: Proposed way to verify HTTPS connections against PVE's root CA
community.general.proxmox_kvm:
api_user: "{{ proxmox_api_user }}"
api_token_id: "{{ proxmox_api_token_id }}"
api_token_secret: "{{ proxmox_api_token_secret }}"
api_host: "{{ proxmox_api_host }}"
name: "{{ hostvars[inventory_hostname]['inventory_hostname_short'] }}"
state: started
validate_certs: "{{ path_to_local_copy_of_pve_root_ca_pem }}"
delegate_to: localhost
Code of Conduct
- I agree to follow the Ansible Code of Conduct
Files identified in the description:
plugins/modules/proxmox
If these files are incorrect, please update the component name
section of the description or use the !component
bot command.
I think this is a very good topic you're raising. It's quite common for teams to set up either self-signed certs or internal PKI in private environments, and then distribute those CA chains to the internal clients. This way TLS can be configured without bypassing warnings.
I propose that we implement the ca_path
module argument similar to the ansible.builtin.uri
module to avoid overloading the validate_certs
module argument. The request's module allows either a boolean, or a path to a CA cert file to manage how the HTTPS trust is handled. I think this could be why the request's module's verify
keyword got misinterpreted or not fully implemented in proxmoxer. It gives the allure of a boolean, where in fact we can also supply a path to a CA cert file.
Unfortunately, the proxmoxer documentation doesn't provide much guidance in terms of customized TLS configuration.
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/uri_module.html#parameter-ca_path
https://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification
https://proxmoxer.github.io/docs/latest/authentication/#https-backend