Bug 1557038 - ansible based deployment fails on iSCSI if the iSCSI password is contained in hostnames or target IQN
Summary: ansible based deployment fails on iSCSI if the iSCSI password is contained in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-ansible-collection
Classification: oVirt
Component: hosted-engine-setup
Version: 1.0.18
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.3.5
: 1.0.18
Assignee: Evgeny Slutsky
QA Contact: Nikolai Sednev
Tahlia Richardson
URL:
Whiteboard:
Depends On: 1720896
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-15 20:24 UTC by Simone Tiraboschi
Modified: 2019-07-30 14:08 UTC (History)
2 users (show)

Fixed In Version: ovirt-ansible-hosted-engine-setup-1.0.18
Clone Of:
Environment:
Last Closed: 2019-07-30 14:08:30 UTC
oVirt Team: Integration
Embargoed:
sbonazzo: ovirt-4.3?
sbonazzo: planning_ack?
sbonazzo: devel_ack+
sbonazzo: testing_ack?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github oVirt ovirt-ansible-hosted-engine-setup pull 186 0 None None None 2019-05-14 08:21:22 UTC

Description Simone Tiraboschi 2018-03-15 20:24:06 UTC
Description of problem:
Ansible based deployment fails on iSCSI if the iSCSI password is contained in hostname or target IQN.

This is not hosted-engine specific and it's due to:
https://github.com/ansible/ansible/issues/19278
When parameter uses no_log=True, the content of parameter obfuscate also other parameter values

So the iSCSI password can partially obscure also hostnames, URLs, IQNs and so on.

We are passing the iSCSI password in:
ovirt_hosts, ovirt_host_storage_facts, ovirt_storage_domains, uri

We had a similar bug on admin password and we solved it passing the admin password with an env variable instead of a module parameter:
https://bugzilla.redhat.com/1539734

Version-Release number of selected component (if applicable):
2.2.13

How reproducible:
100%

Steps to Reproduce:
1. deploy hosted-engine on iSCSI with an iSCSI password (retest also the admin one!) that is contained in IQN or hostname or URL.
2.
3.

Actual results:
[ INFO  ] ok: [localhost]
          The following targets have been found:
              [1]    iqn.2016-08.com.********:sds
                  TPGT: 1, portals:
                      192.168.122.1:3260

and then the login on iqn.2016-08.com.********:sds fails

Expected results:
iqn.2016-08.com.redhat:sds is properly consumed also if the password was redhat

Additional info:

Comment 1 Sandro Bonazzola 2019-01-21 08:28:44 UTC
re-targeting to 4.3.1 since this BZ has not been proposed as blocker for 4.3.0.
If you think this bug should block 4.3.0 please re-target and set blocker flag.

Comment 2 Sandro Bonazzola 2019-02-18 07:54:56 UTC
Moving to 4.3.2 not being identified as blocker for 4.3.1.

Comment 3 hz9595s 2019-02-27 04:05:27 UTC
qhen i  deploy hosted-engine with ansible,i meet iscsi iqn is ********,so led to login failed ,how can i do

Comment 4 Evgeny Slutsky 2019-05-13 12:21:00 UTC
Issue reproduced with this ENV
- hosted-engine upstream 4.3.
- centos 7.6

deployment performed with cockpit: failed on storage iSCSI deyployment with error "Retrieval of iSCSI LUNs failed."

the extra_vars file generated by cockpit contains *** in the target:
cat /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileO2fIl9.var
he_fqdn: engine.es.localvms.com
he_host_name: hosted-engine.es.localvms.com
he_iscsi_username: vagrant
he_iscsi_password: vagrant
he_iscsi_target: iqn.2017-07.ovirt.com:********
he_iscsi_portal_addr: 192.168.100.103
he_iscsi_portal_port: 3260
he_filtered_tokens_vars: ADMIN_PASSWORD,APPLIANCE_PASSWORD,ISCSI_PASSWORD,ISCSI_DISCOVER_PASSWORD,ROOTPWD
he_filtered_tokens_re: BEGIN PRIVATE KEY(?P<filter>.*)END PRIVATE KEY



iscsi configuration:
  tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2017-07.ovirt.com:vagrant
  tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/vdb
  tgtadm --lld iscsi --op new --mode account --user vagrant --password vagrant
  tgtadm --lld iscsi --op bind --mode account --tid 1 --user vagrant
  tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

Comment 5 Evgeny Slutsky 2019-05-14 07:05:17 UTC
the actual obfuscation is performed by the ansible URI module: https://github.com/ansible/ansible/issues/24073
since we are using URI password in hosted-engine-setup:
https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/e6a69d3e2f44cbff289f1488acaa6dcd66293ce3/tasks/iscsi_discover.yml#L26

a possible workaround is not to  use a password option, use Authorization instead:
example:
- uri:
    url: "http://localhost:15672/api/parameters/shovel/{{ vhost }}"
    headers:
      Authorization: "Basic {{ (vhost_user + ':' + vhost_password) | b64encode }}"

https://github.com/ansible/ansible/issues/44635#issuecomment-415771504

Comment 6 Nikolai Sednev 2019-07-16 16:44:10 UTC
Works for me on these components:
rhvm-appliance-4.3-20190710.2.el7.x86_64
ovirt-hosted-engine-ha-2.3.3-1.el7ev.noarch
ovirt-hosted-engine-setup-2.3.11-1.el7ev.noarch
Linux 3.10.0-1061.el7.x86_64 #1 SMP Thu Jul 11 21:02:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.7 (Maipo)


[ INFO  ] changed: [localhost]
          Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs)[nfs]: iscsi
          Please specify the iSCSI portal IP address: 10.35.163.99
          Please specify the iSCSI portal port [3260]: 
          Please specify the iSCSI discover user: root
          Please specify the iSCSI discover password: 
          Please specify the iSCSI portal login user: root
          Please specify the iSCSI portal login password: 
[ INFO  ] Discovering iSCSI targets
[ INFO  ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of steps]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Force facts gathering]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Obtain SSO token using username/password credentials]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Prepare iSCSI parameters]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Fetch host facts]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : iSCSI discover with REST API]
[ INFO  ] ok: [localhost]
          The following targets have been found:
                [1]     iqn.puma18.scl.lab.tlv.redhat.com:sharetarget
                        TPGT: -1, portals:
                                10.35.163.99:3260
         
          Please select a target (1) [1]: 
[ INFO  ] Getting iSCSI LUNs list
[ INFO  ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of steps]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Force facts gathering]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Obtain SSO token using username/password credentials]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : iSCSI login]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Get iSCSI LUNs]
[ INFO  ] ok: [localhost]
          The following luns have been found on the requested target:
                [1]     36589cfc0000009c5bcd15929f1721ac3       97GiB   FreeNAS iSCSI Disk
                        status: free, paths: 1 active
         
          Please select the destination LUN (1) [1]: 
[ INFO  ] iSCSI discard after delete is enabled
[ INFO  ] Creating Storage Domain
[ INFO  ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of steps]
[ INFO  ] ok: [localhost]

Comment 7 Sandro Bonazzola 2019-07-30 14:08:30 UTC
This bugzilla is included in oVirt 4.3.5 release, published on July 30th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.5 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.