Some Background

All openshift admin kubeconfig contain 3 trusted server certificates under `certificate-authority-data`, namely `kube-apiserver-localhost-signer`, `kube-apiserver-service-network-signer` and `kube-apiserver-lb-signer`.

There's another certificate that should be trusted by the kubeconfig, that is the default ingress certificate. However, this certificate is only created late during the late cluster installation finalization stages. The regular openshift installer will attempt to also add the cluster's default ingress certificate as a trusted certificate to the admin kubeconfig file

In a regular non-ABI assisted installation, the initial kubeconfig without the ingress certificate is given as `kubeconfig-noingress`, and then at some point later, the assisted-controller running as a pod on the cluster will fetch the cluster's ingress certificate and post it to the service , which will make the `kubeconfig` file (without `-noingress`) be available with all the required certificates

ABI

We've been trying (MGMT-17884) to run openshift conformance tests on a cluster installed using ABI (we leverage ABI as it's a good fit for what we're trying to test) and have run into some failure that seems to boil down to the kubeconfig provided to us by ABI not having the ingress certificate. The tests expect that certificate to be there so the test is running into certificate errors as it tries to leverage the kubeconfig's certificates to contact ingress routes directly.

Running "openshift-installer wait-for install-complete" will result in a kubeconfig that has the ingress certificate in it

Doing the equivalent agent-based command "openshift-installer agent wait-for install-complete" does not populate the kubeconfig with the cluster's ingress certificate