Bug 1857945 - ovirt: raise a question to users if they would like to continue without TLS verify [NEEDINFO]
Summary: ovirt: raise a question to users if they would like to continue without TLS v...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 4.6
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: 4.7.0
Assignee: Janos Pasztor
QA Contact: Guilherme Santos
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-16 18:52 UTC by Douglas Schilling Landgraf
Modified: 2020-12-03 12:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-03 12:49:03 UTC
Target Upstream Version:
dougsland: needinfo? (adahiya)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift installer pull 3909 0 None closed Bug 1857945: ovirt: if TLS verify is disable raise a question to users 2021-01-18 17:02:32 UTC

Internal Links: 1900138

Description Douglas Schilling Landgraf 2020-07-16 18:52:10 UTC
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

Comment 3 Jan Zmeskal 2020-09-29 10:01:43 UTC
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.

Comment 5 Matthew Staebler 2020-11-20 18:30:54 UTC
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?

Comment 6 Douglas Schilling Landgraf 2020-11-20 19:18:32 UTC
(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.

Comment 7 Janos Pasztor 2020-11-20 19:39:45 UTC
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.

Comment 8 Douglas Schilling Landgraf 2020-11-20 20:28:17 UTC
(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.

Comment 9 Peter Lauterbach 2020-11-20 22:30:54 UTC
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.

Comment 10 Janos Pasztor 2020-11-20 22:47:07 UTC
FYI, added a bug for removing insecure mode: https://bugzilla.redhat.com/show_bug.cgi?id=1900138

Comment 11 Sandro Bonazzola 2020-12-03 12:49:03 UTC
No longer needed, not supporting without TLS verification within installer flow.


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