Description of problem: Today if the installer cannot download the CA from Engine it will continue without enabling TLS verify (connection Insecure). Instead of warning only, let's make sure users agree with that. Expected results: WARNING cannot download PEM file from Engine! Would you like to continue? [? for help] (y/N) <----- here
This does not seem to be working as expected. To simulate a situation, wherein engine certificate is unreachable, I did the following (on engine machine): cd /etc/pki/ovirt-engine mv ca.pem ca.pem.backup systemctl restart ovirt-engine This seem to work, I did the following to verify: curl -k 'https://<engine_fqdn>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA' <html><head><title>Error</title></head><body>Internal Server Error</body></html> Then I tried running openshift-install. But when the installer realized it cannot download the certificate, it just printed this: WARNING cannot detect Engine CA cert imported in the system. Communication with the Engine will be insecure. Ok, so I though that I probably might still have something stored in the OS-wide CA trust. Just to be sure of having a clean env, I did the following: [root@ocp-qe-1 anchors]# pwd /etc/pki/ca-trust/source/anchors [root@ocp-qe-1 anchors]# mkdir /tmp/crt [root@ocp-qe-1 anchors]# mv * /tmp/crt/ [root@ocp-qe-1 anchors]# ll total 0 [root@ocp-qe-1 anchors]# update-ca-trust [root@ocp-qe-1 anchors]# cd ~/primary [root@ocp-qe-1 primary]# ls -l ~/.ovirt ls: cannot access '/root/.ovirt': No such file or directory [root@ocp-qe-1 primary]# ./openshift-install version ./openshift-install 4.6.0-0.nightly-2020-09-28-212756 built from commit 94c4a3afe8492ddf69026b0297fc6b341b575243 release image quay.io/openshift-release-dev/ocp-release-nightly@sha256:3e44bc1f1f031e649f92d89da96d44cc512c5d492a7c0c5fa40b35bef196ae3e [root@ocp-qe-1 primary]# ./openshift-install create install-config --dir=resources/ ? SSH Public Key /root/.ssh/id_rsa.pub ? Platform ovirt ? Engine FQDN[:PORT] <engine_fqdn> WARNING cannot detect Engine CA cert imported in the system. Communication with the Engine will be insecure. ? Engine username [? for help] (admin@internal) <interrupted by Ctrl+C> As you can see, even though I emptied system-wide CA trust and the engine certificate is unreachable, I'm still not presented with the expected question, but simply informed that the communication will be insecure. I believe this is not the intention of the fix.
Is there a legitimate use case for allowing insecure communication in the first place? Would it be better to fail the installation if we cannot use secure communication?
(In reply to Matthew Staebler from comment #5) > Is there a legitimate use case for allowing insecure communication in the > first place? Would it be better to fail the installation if we cannot use > secure communication? My understanding: If the users don't have the sudo power to trust in the CA they still can install it. Additionally, we cannot guarantee all users will run exactly as we expect. I believe it's pretty similar to run openshift installer with openstack cloud.yaml using such params: """ clouds: my_cloud: insecure: true verify: false """ However, let me send the question to PM.
The only way to install it without trusting the cert on a system level and still using certificate verification is by manually adding the certificate to ~/.ovirt/ovirt-config.yaml. #1895874 makes it possible for the user to configure the certificate from the installer which could possibly be a path towards removing the insecure mode from the installer entirely.
(In reply to Janos Pasztor from comment #7) > The only way to install it without trusting the cert on a system level and > still using certificate verification is by manually adding the certificate > to ~/.ovirt/ovirt-config.yaml. Sure but I think Matthew is speaking about IPI installation to fail right away. > #1895874 makes it possible for the user to > configure the certificate from the installer which could possibly be a path > towards removing the insecure mode from the installer entirely. Another call for PM. How others projects deal with that (openstack, baremetal, etc)? The ideal world for IPI - IMO ------------------------------- - Users provide engine FQDN - Installer download the cert and ask users if the cert is the correct one - If yes, the installer looks for the root CA and pass as argument to some internal helper function (from installer API) to download the rootCA and install/trust in the RHCOS nodes. If am not wrong, Abhinav has an enhancement PR for this subject.
By default we should use secure communications and valid certificates during the install. After discussion with dev, if the user doesn't have the privs to update the system trust root, the rhv-m certificates will be saved to their local config yaml. If the user STILL wants to do an insecure install, they'll have configure it manually before they start. There will be another bz for this change.
FYI, added a bug for removing insecure mode: https://bugzilla.redhat.com/show_bug.cgi?id=1900138
No longer needed, not supporting without TLS verification within installer flow.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days