Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue since v6.6.0 with a warning "Attempting to decrypt but no vault secrets found" for all group_vars files with vault variables #2506

Closed
alice-rc opened this issue Sep 27, 2022 · 3 comments · Fixed by #3306
Labels
Milestone

Comments

@alice-rc
Copy link

Summary

All versions since 6.6.0 (6.6.1, 6.7.0) now report the following for all group_vars files with vaulted variables.
NOTE: the environment variable ANSIBLE_VAULT_PASSWORD_FILE is set.

WARNING  Ignored exception from YamllintRule.<bound method YamllintRule.matchyaml of yaml: Violations reported by yamllint.> while processing group_vars/all.yml (vars): Attempting to decrypt but no vault secrets found
Issue Type
  • Bug Report
Ansible and Ansible Lint details
$ ansible --version
ansible [core 2.13.4]
  config file = /home/julie.blake/venv/ee-183-lint/meta/ansible.cfg
  configured module search path = ['/home/julie.blake/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/julie.blake/venv/ee-183-lint/lib64/python3.9/site-packages/ansible
  ansible collection location = /home/julie.blake/venv/ee-183-lint/collections
  executable location = /home/julie.blake/venv/ee-183-lint/bin/ansible
  python version = 3.9.7 (default, Apr 11 2022, 06:30:15) [GCC 8.5.0 20210514 (Red Hat 8.5.0-10.0.1)]
  jinja version = 3.1.2
  libyaml = True
$ ansible-lint --version
ansible-lint 6.7.0 using ansible 2.13.4
$ ansible-lint --version
ansible-lint 6.6.1 using ansible 2.13.4
$ ansible-lint --version
ansible-lint 6.6.0 using ansible 2.13.4
  • ansible installation method: pip
  • ansible-lint installation method: pip
OS / ENVIRONMENT
$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.6"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.6"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.6"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:6:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.6
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.6
STEPS TO REPRODUCE

Can't provide you with the ACTUAL group_vars files, but they are standard vault encrypted variables. One example is below.

ldap_password: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  35323062386261383633623963303361313937653837333033613933623434343138663331336164
  3534373564393166656664306537633035613962356662645a316562353832363736313935383665
  33306432623765646338303236363061326538653163643466643446716164326364643937623365
  6239383765373639390a646361343566353934633532376231653838386231653865386665303733
  34336534613538326639306139363538306636383463663437643466653064646363
Desired Behavior

I want to understand what this error actually means, since it is clearly NOT an error or warning coming from yamllint. And it also didn't happen in any of the versions of ansible-lint that I tried that were lower than v6.6.0.

$ ansible-lint -P production. # ansible-lint 6.5.2
Returns nothing
$ ansible-lint -P production  # ansible-lint 6.5.1, 6.5.0
Returns some  bogus (jinja[spacing]) warnings, but none about 'no vault secrets found'
Actual Behavior
$ ansible-lint -P production  ## ansible-lint 6.6.0, 6.6.1, 6.7.0
WARNING  Ignored exception from YamllintRule.<bound method YamllintRule.matchyaml of yaml: Violations reported by yamllint.> while processing group_vars/lab.yml (vars): Attempting to decrypt but no vault secrets found
WARNING  Ignored exception from YamllintRule.<bound method YamllintRule.matchyaml of yaml: Violations reported by yamllint.> while processing group_vars/stage.yml (vars): Attempting to decrypt but no vault secrets found
WARNING  Ignored exception from YamllintRule.<bound method YamllintRule.matchyaml of yaml: Violations reported by yamllint.> while processing group_vars/all.yml (vars): Attempting to decrypt but no vault secrets found
WARNING  Ignored exception from YamllintRule.<bound method YamllintRule.matchyaml of yaml: Violations reported by yamllint.> while processing group_vars/prod.yml (vars): Attempting to decrypt but no vault secrets found
WARNING  Ignored exception from YamllintRule.<bound method YamllintRule.matchyaml of yaml: Violations reported by yamllint.> while processing group_vars/qa.yml (vars): Attempting to decrypt but no vault secrets found
WARNING  Ignored exception from YamllintRule.<bound method YamllintRule.matchyaml of yaml: Violations reported by yamllint.> while processing group_vars/uat.yml (vars): Attempting to decrypt but no vault secrets found
$ yamllint .
Returns nothing
@AndrewKvalheim
Copy link

It’s not clear to me what action I’m expected to take to resolve this. Expose secrets to a linter?

@ktomk
Copy link

ktomk commented Mar 30, 2023

@AndrewKvalheim Yes, good question, and thinking: May I suggest regarding your comment and question?

The linter should know about the "!vault" YAML Tag 1 and where its use is applicable, so that linting supports it as encoded 2 in the file (binary stream).

For this, exposing the secrets to the linter does not look necessary to me. More the contrary, as the current diagnostic message suggests to me, not only should the secrets not be exposed to the linter, but, the linter should not expose the parsing of the encrypted value/s at and after the point the linter starts to require secrets to do its job.

To resolve this, I'd suggest to build-back the parsing of !vault serializations to just linting the format of such data rather than decoding it.

In my opinion, the linter not being able to transform a secret into a plain is not an error or a warning, not even something to inform about or to offer diagnostics for. The current messages' only reason to exist - as I understand it - is to inform any user of the utility 3 about its limitations and the flaw to process Ansible documents containing !vault tags. However, it is unknown to me why the linter didn't just treat the data-type as string and not further leave it as-is. This might be a limitation of the linting infrastructure in use.

Rationale is that this is a linter, not a decrypter. 4

From your perspective, would you consider such another reduced approach more feasible than the proposed disclosing publishing of ansible vault password stores to the linter? Or would what I've outlined actually break the overall linting infrastructure of the current design?


  1. Oren Ben-Kiki, Clark Evans, Ingy döt Net; YAML Ain’t Markup Language (YAML™) version 1.2; Revision 1.2.2 (2021-10-01), 6.8.2.1. Tag Handles --- In concrete a Primary Tag Handle
  2. Ansible project contributors; Ansible Documentation Last updated on Mar 17, 2023; Encrypting individual variables with Ansible Vault (archived copy)
  3. Red Hat, Inc.; Ansible Lint (the ansible-lint(1) user command)
  4. Rationale context with Principle of least privilege: "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job." --- Saltzer, Jerome H.; Protection and the control of information sharing in multics; Communications of the ACM 17 (7): 388–402 (1974);

/EE: typo, better archived version.

@ktomk
Copy link

ktomk commented Apr 12, 2023

We updated Ansible to current stable recently and it needed changes for the remote CI pipeline we have for ansible-lint (reason: clean git checkout). While previously we got the warning as reported, changing to ansible-lint 6.14.4 using ansible 2.14.4 removed the warning but required the ansible vault password file as configured (here exemplarly a file named .ansible-vault-password). The file must exist and it must be larger than zero bytes in size.

if [ ! -e .ansible-vault-password ]; then
  echo "FAKE-FOR-ANSIBLE-LINT" > .ansible-vault-password;
fi

With the verbatim fake data "FAKE-FOR-ANSIBLE-LINT" the remote build went green again.

Details

In use in this scenario was the Microsoft Github Action ansible-community/ansible-lint-action@v6.

The error message with the missing file:

internal-error: Unexpected error code 1 from execution of: ansible-playbook -i localhost, --syntax-check plays/file.yml
Warning: plays/file.yml:1 [WARNING]: Error getting vault password file (default): The vault password file
/github/workspace/.ansible-vault-password was not found
ERROR! The vault password file /github/workspace/.ansible-vault-password was not found

Ansible configuration in project:

$ ansible-lint --version
ansible-lint 6.14.4 using ansible 2.14.4
$ ansible-vault --version
ansible-vault [core 2.14.4]
  config file = /home/user/workspace/group/project/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/user/workspace/group/project/.direnv/python-venv-3.10.6/lib/python3.10/site-packages/ansible
  ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/user/workspace/group/project/.direnv/python-venv-3.10.6/bin/ansible-vault
  python version = 3.10.6 (main, Mar 10 2023, 10:55:28) [GCC 11.3.0] (/home/user/workspace/group/project/.direnv/python-venv-3.10.6/bin/python)
  jinja version = 3.1.2
  libyaml = True

It is a bit early, but it looks to me that it is already possible with ansible-lint 6.14.4 using ansible 2.14.4 to not provide real credentials without any further errors, which is good in my eyes. The Ansible Vault configuration still leaks through though.

@alice-rc Maybe you want to try the current version with a setup that is using the environment parameter ANSIBLE_VAULT_PASSWORD_FILE?

ssbarnea added a commit that referenced this issue Apr 19, 2023
ssbarnea added a commit that referenced this issue Apr 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants