search

ansible-collections / community.hashi_vault

Ansible collection for managing and working with HashiCorp Vault.
https://docs.ansible.com/ansible/devel/collections/community/hashi_vault/index.html
GNU General Public License v3.0
80 stars 59 forks source link

New environment variable scheme causes issues in some usage #85

Closed wenottingham closed 3 years ago

wenottingham commented 3 years ago
SUMMARY

Hi - I was pointed here by https://github.com/ansible/awx/issues/10275.

In AWX, we let users create custom credentials to pass secrets/info to playbooks for use by modules. However, we do not allow any custom credentials that pass variables that start with ANSIBLE - allowing a user delegated access to a playbook to pass arbitrary ANSIBLE* parameters is a security risk, as they can change ansible behavior in unexpected ways (think ANSIBLE_SSH_EXECUTABLE, ANSIBLE_COLLLECTION_PATHS, and other things).

This means that at least in AWX, we can't allow users to create a custom credential that uses the new variables in use by v2 of this collection.

Is it possible to keep the legacy variables?

ISSUE TYPE
COMPONENT NAME

community.hashi_vault

ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT

under AWX, or Ansible Automation Platform

cc @infra-monkey

briantist commented 3 years ago

Hey @wenottingham , thanks for submitting! This has been brought up in the past and the current open issue for it is #49 (I should rename the title probably to clarify). To understand to reasoning behind the changes (and which specific changes being made) it'll be helpful to look at #10 and the individual issues linked to that one..

I'll close this issue so the conversation can be moved over to there, but I'll briefly explain as well, that first off I don't have any experience with AWX/tower, so I don't fully understand the system or how it works.

What I will say that it seems wrong to me, to fully restrict setting those environment variables that begin with ANSIBLE_. To warn that it may be changing key settings? Sure. But the fact is that using an ANSIBLE_ prefix is the main way of designating variables for use in something specific to Ansbile.

Again I don't use AWX, so I don't really get why it's a security risk that you can set env vars before invoking Ansible, any more than it's a risk that someone runs ANSIBLE_SSH_EXECUTABLE=whatever ansible-playbook playbook.yml. I guess the key is in your use of the word "delegation" (I'm supposing it's some kind of thing where you allow normally unprivileged users to run Ansible in a privileged way?).

In any case, given that the ANSIBLE_ prefix is pretty standard across the whole of not only Ansible Core but within most collections (especially the ones included in the Ansible package), I think it should be configurable by an admin in AWX to determine a blocklist/allowlist of overridable variables at least.

Unfortunately, for the reasons outlined in #10, retaining the original variables isn't something we're looking to do across the board (some are being retained, with lower precedence, due to their use in Vault CLI), and sticking to a standard that aligns closely with the rest of the Ansible-using world makes more sense in my opinion than aligning with AWX's indiscriminate blocking of all ANSIBLE_* vars.

That being said I don't want to unnecessarily break usage for AWX users, so as outlined in #49 , the plan is to add Ansible vars as another way of setting the values, and from testing by affected users, that seems to be compatible with the AWX credential option. In that way, instead of setting an environment variable like ANSIBLE_HASHI_VAULT_TOKEN the credential can set an Ansible variable ansible_hashi_vault_token and the plugin would accept the existing options to be set via Ansible var (just like some other plugins do).

I expect that work to be completed before version 2.0.0 of the collection (when some of the deprecated env vars will be removed), that way there is a bridge for AWX users.