Cannot pipe the vault password via stdin ansible-playbook when ran without a tty #30993
Assignees
Labels
affects_2.4
This issue/PR affects Ansible v2.4
affects_2.5
This issue/PR affects Ansible v2.5
bug
This issue/PR relates to a bug.
c:cli/vault
support:core
This issue/PR relates to code supported by the Ansible Engineering Team.
Comments
ansibot
added
affects_2.4
jborean93
removed
the
needs_triage
|
I can reproduce that... ... doesn't work in 2.4, but I can't reproduce the rest. For me, on 2.4.0.0, I get: But it also fails on 2.3, 2.2, and 2.1 2.3 2.2 2.1 |
|
@sebastianneubauer paste the 'ansible --version' and an example output of ansible 2.3 working? |
alikins
added
needs_info
|
I can reproduce the 'ERROR! Attempting to decrypt but no vault secrets found' error with 2.4, if the playbook I am using is vault encrypted. In this case, 'ping_noop.yml' has been vault-encrypted with the password 'password' But it also doesn't work on 2.3: Or 2.2: Or 2.1: |
|
crazy, in my local bash, similar to you I cannot get this sdtin/echo thing to work also with 2.3...But in Jenkins it works And this is the snipped from my Jenkinsfile: So I must admit: maybe it was pure luck that it worked so far for me. But is there a good way to inject the vault password via environment variables? echoing the environment variable into a file and using this seems really to be a very bad workaround...needing a script which reads out the environment variable also feels like a big mess, as I would have to have such a "boilerplate" script in all my ansible projects... |
ansibot
removed
the
needs_info
|
@alikins I think that after the merge of #22756 (Support of multiple vault passwords), the vault password is no longer captured by the Python See
|
|
@gildegoma It still uses getpass.getpass() eventually. https://github.com/ansible/ansible/blob/devel/lib/ansible/parsing/vault/__init__.py#L280 PromptVaultSecret classes uses ansible.utils.display.Display.prompt(private=True) and display.Display.prompt() uses getpass.getpass() |
|
2.4.0 checks if sys.stdin.isatty() to decide if it should show the interactive prompt (eventually via getpass.getpass()). But for cases that aren't via tty (likely vagrant and jenkins cases), that means it never calls PromptVautlSecret() or getpass.getpass(). But... getpass.getpass() will fallback to reading from stdin if it is not a tty. Since 2.3 will always call getpass.getpass(), it will eventually fallback to stdin via getpass() if there isnt a tty. Testing against 2.4 without a tty: But running same command with 2.3 without a tty works as mentioned above: Fix seems to be just to remove the isatty() check. stable-2.4 + rm that check: diff --git lib/ansible/cli/__init__.py lib/ansible/cli/__init__.py
index 3660e4b..706e252 100644 some_name@prompt_ask_vault_pass --vault-id other_name@prompt_ask_vault_pass will be a little
--- lib/ansible/cli/__init__.pynce it will use the old format without the vault id in the prompt
+++ lib/ansible/cli/__init__.py.4 % u-9)]$ fg
@@ -259,10 +259,6 @@ class CLI(with_metaclass(ABCMeta, object)):
vault_id_name, vault_id_value = CLI.split_vault_id(vault_id_slug)
if vault_id_value in ['prompt', 'prompt_ask_vault_pass']:
- # prompts cant/shouldnt work without a tty, so dont add prompt secrets
- if not sys.stdin.isatty():
- continue
-
# --vault-id some_name@prompt_ask_vault_pass --vault-id other_name@prompt_ask_vault_pass will be a little
# confusing since it will use the old format without the vault id in the prompt
built_vault_id = vault_id_name or C.DEFAULT_VAULT_IDENTITY |
|
proposed fix at #31493 |
alikins
changed the title
|
@alikins Sorry for my too simplistic and erroneous analysis (I hadn't taken yet enough time to dig into it, and shouldn't have conclude anything so quickly). |
|
Not sure that fix makes sense for all cases. It seems to confuse the cases without any thing on stdin, since it can block. And in the cases where we try to show an interactive prompt if needed even without --ask-vault-pass also seems odd (the non-tty cases seem to work but not sure if the tty case behavior is correct) |
@alikins How does it compare to |
alikins
added a commit
that referenced
this issue
Nov 15, 2017
* Fix vault --ask-vault-pass with no tty
2.4.0 added a check for isatty() that would skip setting up interactive
vault password prompts if not running on a tty.
But... getpass.getpass() will fallback to reading from stdin if
it gets that far without a tty. Since 2.4.0 skipped the interactive
prompts / getpass.getpass() in that case, it would never get a chance
to fall back to stdin.
So if 'echo $VAULT_PASSWORD| ansible-playbook --ask-vault-pass site.yml'
was ran without a tty (ie, from a jenkins job or via the vagrant
ansible provisioner) the 2.4 behavior was different than 2.3. 2.4
would never read the password from stdin, resulting in a vault password
error like:
ERROR! Attempting to decrypt but no vault secrets found
Fix is just to always call the interactive password prompts based
on getpass.getpass() on --ask-vault-pass or --vault-id @prompt and
let getpass sort it out.
* up test_prompt_no_tty to expect prompt with no tty
We do call the PromptSecret class if there is no tty, but
we are back to expecting it to read from stdin in that case.
* Fix logic for when to auto-prompt vault pass
If --ask-vault-pass is used, then pretty much always
prompt.
If it is not used, then prompt if there are no other
vault ids provided and 'auto_prompt==True'.
Fixes vagrant bug hashicorp/vagrant#9033
Fixes #30993
alikins
added a commit
that referenced
this issue
Nov 15, 2017
* Fix vault --ask-vault-pass with no tty
2.4.0 added a check for isatty() that would skip setting up interactive
vault password prompts if not running on a tty.
But... getpass.getpass() will fallback to reading from stdin if
it gets that far without a tty. Since 2.4.0 skipped the interactive
prompts / getpass.getpass() in that case, it would never get a chance
to fall back to stdin.
So if 'echo $VAULT_PASSWORD| ansible-playbook --ask-vault-pass site.yml'
was ran without a tty (ie, from a jenkins job or via the vagrant
ansible provisioner) the 2.4 behavior was different than 2.3. 2.4
would never read the password from stdin, resulting in a vault password
error like:
ERROR! Attempting to decrypt but no vault secrets found
Fix is just to always call the interactive password prompts based
on getpass.getpass() on --ask-vault-pass or --vault-id @prompt and
let getpass sort it out.
* up test_prompt_no_tty to expect prompt with no tty
We do call the PromptSecret class if there is no tty, but
we are back to expecting it to read from stdin in that case.
* Fix logic for when to auto-prompt vault pass
If --ask-vault-pass is used, then pretty much always
prompt.
If it is not used, then prompt if there are no other
vault ids provided and 'auto_prompt==True'.
Fixes vagrant bug hashicorp/vagrant#9033
Fixes #30993
(cherry picked from commit 86dc3c0)
|
As @gildegoma noted, it is currently not possible to pipe a password for My idea was asking for a password immediately after running my provisioning script, instead of waiting for |
|
I deploy/re-deploy a lot local container instances here, it's a bit combursome to re-enter the same password multiple times. I'm curious, is there any movement for this for |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
ISSUE TYPE
COMPONENT NAME
ansible-playbook
ANSIBLE VERSION
CONFIGURATION
DEFAULT_ROLES_PATH(/vagrant/ansible.cfg) = [u'/vagrant/common_roles', u'/vagrant/{{ roles_path }}']
OS / ENVIRONMENT
Debian jessie
SUMMARY
Since version 2.4.0.0 one cannot pipe the vault password via stdin into ansible-playbook anymore
STEPS TO REPRODUCE
This works in version <2.4.0.0
echo "secret_vault_pass" | ansible-playbook deploy_with_vaulted_file.yml --ask-vault-passSince version 2.4.0.0 this results in
ERROR! Attempting to decrypt but no vault secrets foundSame happens with the new vault_id parameter:
echo "secret_vault_pass" | ansible-playbook deploy_with_vaulted_file.yml --vault-id @promptresults in the error:
ERROR! Attempting to decrypt but no vault secrets foundIs this on purpose or is it a bug?
The text was updated successfully, but these errors were encountered: