Description of problem: During HE deployment via cockpit-ovirt, cockpit-ovirt generates an ansible variable file which contains the admin and the appliance passwords as plain-text. At the of the deployment procedure, these files are deleted. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Login to https://<host fqdn or IP>:9090 2. Start the HE wizard -> fill the required data in VM and ENGINE section and press 'Deploy' 3. When the procedure starts open the browser's console tab by clicking F12 and navigate to 'console' tab 4. find the following log message: Phase BOOTSTRAP_VM variable file successfully created: /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var 5. execute : cat /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var to view the variable file - you should see the 2 passwords in clear-text Actual results: passwords are in clear-text Expected results: passwords should be encrypted (with ansible-vault for example) Additional info: -
Test Version rhvh-4.3.0.6-0.20190418.0+1 cockpit-dashboard-176-4.el7.x86_64 cockpit-bridge-176-4.el7.x86_64 cockpit-storaged-176-4.el7.noarch cockpit-176-4.el7.x86_64 cockpit-system-176-4.el7.noarch cockpit-ws-176-4.el7.x86_64 cockpit-machines-ovirt-176-4.el7.noarch cockpit-ovirt-dashboard-0.12.8-1.el7ev.noarch Test steps: 1. Login to https://<host fqdn or IP>:9090 2. Start the HE wizard -> fill the required data in VM and ENGINE section and press 'Deploy' 3. When the procedure starts open the browser's console tab by clicking F12 and navigate to 'console' tab 4. find the following log message: Phase BOOTSTRAP_VM variable file successfully created: /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var 5. cat /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var to view the variable file Result: Application password and admin password are in clear-text. QE can reproduce this bug, ack+
(In reply to Ido Rosenzwig from comment #0) > Actual results: > passwords are in clear-text > > > Expected results: > passwords should be encrypted (with ansible-vault for example) I do not object to that, but then we'll have to somehow protect the vault's password, so it's not a simple solution either. 100170 changes the permissions on the directory. Should probably be enough for current bug.
We discussed this in private and came up with what seems like a better approach: Pass the variables to ansible via a custom fd. Will require more work, we might postpone this to a later version (and bug).
Moving back to POST as the solution is not complete yet.
Ido, please see my comment on https://gerrit.ovirt.org/100255 . Thanks.
replied.
Moving changes 100170 and 100178 to a new bug 1714153, these are already merged/built for 4.3.4.
Moving back to ASSIGNED because imo the current fix is not secure enough, even though much better than nothing.
QE will verify it until getting new build.
Test Version RHVH-4.3-20190620.7-RHVH-x86_64-dvd1.iso cockpit-system-195-1.el7.noarch cockpit-195-1.el7.x86_64 cockpit-bridge-195-1.el7.x86_64 cockpit-ws-195-1.el7.x86_64 cockpit-machines-ovirt-195-1.el7.noarch cockpit-dashboard-195-1.el7.x86_64 cockpit-storaged-195-1.el7.noarch cockpit-ovirt-dashboard-0.13.2-2.el7ev.noarch Test Steps: According to comment 1 Result: Application password and admin password are not in clear-text. [root@dell-perxxx-xx ~]# cat /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileHThRJZ.var he_local_vm_dir_path: /var/tmp he_local_vm_dir_prefix: localvm he_filtered_tokens_vars: ['ADMIN_PASSWORD','APPLIANCE_PASSWORD','ISCSI_PASSWORD','ISCSI_DISCOVER_PASSWORD','ROOTPWD','he_appliance_password','he_admin_password','he_iscsi_password','he_iscsi_discover_password','ansible_ssh_pass'] he_filtered_tokens_re: ['BEGIN PRIVATE KEY(?P<filter>.*)END PRIVATE KEY'] he_enable_hc_gluster_service: false he_bridge_if: em1 he_bridge: ovirtmgmt he_fqdn: rhevh-hostedengine-vm-xx.lab.eng.pek2.redhat.com he_host_address: dell-perxxx-xx.lab.eng.pek2.redhat.com he_vcpus: 4 he_maxvcpus: 24 he_cpu_sockets: 1 he_emulated_machine: null he_vm_uuid: 169bf9f7-a3c5-468d-90ac-f6631fa0e7e7 he_vm_mac_addr: "52:54:00:34:04:b0" he_mem_size_MB: 16384 he_vm_ip_addr: null he_vm_ip_prefix: null he_time_zone: Asia/Shanghai he_appliance_ova: null he_cloud_init_host_name: rhevh-hostedengine-vm-xx he_cloud_init_domain_name: lab.eng.pek2.redhat.com he_root_ssh_pubkey: null he_root_ssh_access: "yes" he_vm_etc_hosts: true he_apply_openscap_profile: false he_cdrom_uuid: null he_cdrom: null he_nic_uuid: null he_console_uuid: null he_video_device: vga he_graphics_device: vnc he_vm_name: HostedEngine he_enable_libgfapi: null he_host_name: dell-perxxx-xx.lab.eng.pek2.redhat.com he_console_type: vnc he_cpu_type: model_Conroe QE cannot reproduce this bug, verified.
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.