hashi_vault does not use VAULT_ADDR environment variable anymore

[Akasurde]

From @transferkraM on Feb 23, 2021 15:23

SUMMARY

Before 3.0, hashi_vault functions properly with VAULT_ADDR and VAULT_TOKEN environment variables. Starting with 3.0 ANSIBLE_HASHI_VAULT_ADDR is required.

ISSUE TYPE

• Bug Report

COMPONENT NAME

hashi_vault lookup plugin.

ANSIBLE VERSION

NOTE: Various irrelevant path information is abbreviated as <>.

ansible 2.10.5
  config file = <>/ansible.cfg
  configured module search path = ['<>/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = <>/.local/lib/python/versions/ansible/lib/python3.9/site-packages/ansible
  executable location = <>/.local/lib/python/versions/ansible/bin/ansible
  python version = 3.9.1 (default, Feb  6 2021, 06:49:13) [GCC 10.2.0]

CONFIGURATION

ANSIBLE_COW_SELECTION(<>/ansible.cfg) = random
ANSIBLE_NOCOWS(env: ANSIBLE_NOCOWS) = True
ANSIBLE_PIPELINING(<>/ansible.cfg) = True
ANSIBLE_SSH_ARGS(<>/ansible.cfg) = -F ssh_config -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/tmp/%p:%r@%h
DEFAULT_GATHERING(<>/ansible.cfg) = smart
DEFAULT_LOAD_CALLBACK_PLUGINS(<>/ansible.cfg) = True
DEFAULT_ROLES_PATH(<>/ansible.cfg) = ['<>/roles']
DEFAULT_VAULT_PASSWORD_FILE(<>/ansible.cfg) = <>/vault
DISPLAY_SKIPPED_HOSTS(<>/ansible.cfg) = False
HOST_KEY_CHECKING(<>/ansible.cfg) = False
INTERPRETER_PYTHON(<>/ansible.cfg) = auto_legacy_silent
RETRY_FILES_ENABLED(<>/ansible.cfg) = False

OS / ENVIRONMENT

pyenv virtualenvs|ag ansible

ansible (created from /usr)

pyenv activate ansible
python --version

Python 3.9.1

STEPS TO REPRODUCE

export VAULT_ADDR=http://127.0.0.42:12345
sudo tcpdump -i lo port 12345
ansible ...

export ANSIBLE_HASHI_VAULT_ADDR=$VAULT_ADDR   # e.g. http://127.0.0.42:12345 (see above)
nc -l -p 12345 -s 127.0.0.42:12345
sudo tcpdump -i lo port 12345
ansible ...

some_var: '{{ lookup("community.hashi_vault.hashi_vault", "secret=foo/data/bar")

EXPECTED RESULTS

• VAULT_ADDR is respected (again) and wins over all other possible configuration values!

ACTUAL RESULTS

• VAULT_ADDR is not evaluated/used

Copied from original issue: ansible/ansible#73698

[briantist]

Thanks for reporting @transferkraM , I will look into this, as it definitely should not be the expected behavior.

[briantist]

I think I know why this is happening. I will confirm and look at doing a bugfix release of the collection.

[briantist]

@transferkraM I have a fix in #61

Wanted to address this:

VAULT_ADDR is respected (again) and wins over all other possible configuration values!

The change from VAULT_ADDR winning over all other possible configuration values was intentional, via #41 ( see also #10 ).
It should still remain working, however it's meant to be the last value used, so that you may override it in ansible.cfg.

[ghost]

First of all thanks a lot for this exemplary reaction on that bug report, including to move it to the correct location. That's amazing.

I'm not sure though how to test in a real world scenario based on #61. I'd love to provide useful feedback. As far as I understand, the PR looks good, but I'm not an expert and I don't want to pollute #61 with useless commentary.

[briantist]

@transferkraM thanks and no worries. The change has been merged and a new version of the collection has been released, so you can now upgrade your collection version to get the fix:

• Galaxy release: https://galaxy.ansible.com/community/hashi_vault
• GitHub release: https://github.com/ansible-collections/community.hashi_vault/releases/tag/1.1.1

[elcomtik]

Thanks a lot @briantist

[ghost]

Confirmed with 3.0 and manual installation of the "collection" (whatever that means though ;)). Thanks a lot!

[briantist]

@transferkraM

"collection" (whatever that means though ;))

A big reason for the work in the refactor project (beyond better testing) is to make writing additional plugins and modules much easier, while ensuring consistency between them. When that work is reaches a tipping point, I expect to start introducing new content, so stay tuned!

Thank you for following up and confirming!