-
Bug
-
Resolution: Not a Bug
-
Undefined
-
None
-
rhel-9.5
-
None
-
None
-
rhel-sst-ansible
-
None
-
False
-
-
None
-
Red Hat Enterprise Linux
-
None
-
None
-
None
-
x86_64
-
None
What were you trying to do that didn't work?
I was joining servers to AD through Ansible playbooks. My admin password was passed through a private variable defined when running the playbook:
- name: "bind_password"
prompt: "Password for *:"
private: yes
no_log: true
And used in an "expect" bracket later in the playbook:
- name: Join system to AD if not already joined
expect:
command: /usr/sbin/realm join DOMAIN --user={{ ad_user }}
responses:
Password for *: "{{ bind_password }}"
When running the playbook, the "Join system to AD if not already joined" task fails prior to the password prompt. When looking through the journalctl logs to troubleshoot the issue, I found my password in plaintext on the form below:
python[]: ansible-expect Invoked with command=/usr/sbin/realm join "DOMAIN" --user="USER" responses={'Password for *': 'PASSWORD'} echo=False timeout=30 chdir=None creates=None removes=None
Where "PASSWORD" was my password in plaintext. Expected result would be for it to not show at all. I assume this might be a general issue when using the Ansible "expect" bracket and receiving an error before the expected prompt comes up.
What is the impact of this issue to you?
Cannot safely use my password when running Ansible playbooks.
Please provide the package NVR for which the bug is seen:
Name : ansible
Version : 2.9.27
RHEL version 8.10 on Ansible server. RHEL version 9.5 on target servers.
How reproducible is this bug?:
Very.
Steps to reproduce
- Create an Ansible playbook using private variables and the "expect"-bracket. Use the private variable as an answer to the prompt in the expected bracket. Make sure the command in the expect bracket fails prior to the prompt.
- Run the playbook. Input the private variable. Run the playbook until it fails.
- See journalctl logs on the target server and look for the python log as seen in the problem description above. There you'll find your private variable in plaintext.
- I am not sure if this problem is unique to using "realm join". If that is the case, one should try to reproduce the error using the information I have given in the problem description.
Expected results
No passwords shown in plaintext in logs on target server.
Actual results
Passwords shown in plaintext in logs on target server.