Description of problem: Prompted with certificate signed by an unknown authority when logging in using a kubeconfig file that is using a current context with a server defined that does not include the port. Version-Release number of selected component (if applicable): 3.2 3.3 How reproducible: 100% Steps to Reproduce: 1. Install an multi master environment with the default LB. Use a anisble inventory where yo chang ethe cluster hostname and master api port to use port 443. # Native high availability cluster method with optional load balancer. openshift_master_cluster_method=native openshift_master_cluster_hostname=openshift.example.com openshift_master_cluster_public_hostname=openshift.public.example.com # Configure master API and console ports. openshift_master_api_port=443 openshift_master_console_port=443 2. The admin.kubeconfig file that gets created has a cluster defined using a server URL that does not include port 443 (since its defaulted with https). [root@master-1 ~]# cat .kube/config clusters - cluster: certificate-authority-data: XXXXDATAXXXX server: https://openshift.example.com name: openshift-example-com:443 .. .. .. 3. Run `oc login` [root@master-1 ~]# oc login -u system:admin The server uses a certificate signed by an unknown authority. You can bypass the certificate check, but any data you send to the server could be intercepted by others. Use insecure connections? (y/n): 4. To correct set the cluster server to the URL:PORT [root@master-1 ~]# oc config set-cluster openshift-example-com:443 --server=https://openshift.example.com:443 --certificate-authority=/etc/origin/master/ca.crt --config=.kube/config --embed-certs=true cluster "openshift-example-com:443" set. [root@master-1 ~]# oc login -u system:admin Logged into "https://openshift.example.com:443" as "system:admin" using existing credentials. You have access to the following projects and can switch between them with 'oc project <projectname>': 5. To break run # oc config set-cluster openshift-example-com:443 --server=https://openshift.example.com --certificate-authority=/etc/origin/master/ca.crt --config=.kube/config --embed-certs=true Actual results: server uses a certificate signed by an unknown authority. Expected results: To log in using the CA defined in the kubeconfig file Additional info: I see this as more of a bug with `oc login` command most likely not using the CA defined in the kubeconfig due to some issue with the port not being defined. We can work around this by modifying the installer if fixing `oc login` is not possible, by adding the api port when creating master certs. https://github.com/openshift/openshift-ansible/blob/master/roles/openshift_master_certificates/tasks/main.yml#L53-L65 - name: Create the master certificates if they do not already exist command: > {{ openshift.common.client_binary }} adm create-master-certs {% for named_ca_certificate in openshift.master.named_certificates | default([]) | oo_collect('cafile') %} --certificate-authority {{ named_ca_certificate }} {% endfor %} --hostnames={{ openshift.common.all_hostnames | join(',') }} --master={{ openshift.master.api_url }}:{{ openshift.master.api_port }} --public-master={{ openshift.master.public_api_url }}:{{ openshift.master.api_port }} --cert-dir={{ openshift_master_generated_config_dir }} --overwrite=false when: master_certs_missing | bool and inventory_hostname != openshift_ca_host delegate_to: "{{ openshift_ca_host }}"
Related PR: https://github.com/openshift/origin/pull/12591
Which version should QE test against? Will the fix be back to 3.2?
Please test with latest master. Not sure if this will be backported to 3.2, ffranz?
This is OCP so I'm setting to MODIFIED until QE gets a build that includes this. No backport planned, so expect this to be only in 3.5.
This has been merged into ocp and is in OCP v3.5.0.10 or newer.
Does it need to be tested on HA masters with LB? If it's yes, will test it when the blocker bug is fixed for c0 step1 "multi master environment with the default LB" Bug 1419026 - openshift_master_certificates task failed when installing multiple masters env
> Does it need to be tested on HA masters with LB? I have cc'd Maciej to verify, but yes, per the description in comment 0, this should be tested on a multi master env with a LB once the blocker is fixed. Moving back to ON_QA
Yes, if that's the root cause it should be verified, though it looks like it already was :)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:0884