Description of problem: While testing Open Shift Service Mesh on OCP 4.5 (4.5.0-rc.1), Kiali login fails with: {"error":"Error authenticating (getting business layer)","detail":"failed to get root CA certificates: open /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt: no such file or directory"} Also jaeger-query pod fails to start: {"level":"fatal","ts":1591779135.5996642,"caller":"agent/main.go:62","msg":"Could not create collector proxy","error":"failed to load TLS config: failed to load CA CertPool: failed to load CA /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt: open /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt: no such file or directory","stacktrace":"main.main.func1\n\t/go/src/github.com/jaegertracing/jaeger/cmd/agent/main.go:62\ngithub.com/jaegertracing/jaeger/vendor/github.com/spf13/cobra.(*Command).execute\n\t/go/src/github.com/jaegertracing/jaeger/vendor/github.com/spf13/cobra/command.go:762\ngithub.com/jaegertracing/jaeger/vendor/github.com/spf13/cobra.(*Command).ExecuteC\n\t/go/src/github.com/jaegertracing/jaeger/vendor/github.com/spf13/cobra/command.go:852\ngithub.com/jaegertracing/jaeger/vendor/github.com/spf13/cobra.(*Command).Execute\n\t/go/src/github.com/jaegertracing/jaeger/vendor/github.com/spf13/cobra/command.go:800\nmain.main\n\t/go/src/github.com/jaegertracing/jaeger/cmd/agent/main.go:98\nruntime.main\n\t/opt/rh/go-toolset-1.13/root/usr/lib/go-toolset-1.13-golang/src/runtime/proc.go:203"} Version-Release number of selected component (if applicable): 4.5.0-rc.1 How reproducible: Always Steps to Reproduce: 1. Deploy Openshift Service Mesh operators (Elastic Search, Jaeger, Kiali, and Service Mesh) 2. Create OSSM Control Plane * Note that the Jaeger pod fails to start * Attempt to login to Kiali, also fails with a crt error Actual results: Jaeger pod fails to start Expected results: Jaeger pod should start succesfully Additional info:
The behavior being used here was deprecated in 4.1. it was removed during a very brief window during the 4.5 development cycle. However it has been re-added. The reliance on this certificate in this way will be removed in 4.6. documentation on the service certificate in the OpenShift docs describe the appropriate way to use an annotation in order to gain access to this information. You will need to switch to that method immediately.
As per the bz that this duplicates, this regression has been verified resolved as of 4.5.0-0.nightly-2020-06-09-223121. To avoid breakage the potential for breakage in the future, please switch to sourcing the service ca via configmap injection: https://docs.openshift.com/container-platform/4.4/authentication/certificates/service-serving-certificate.html#add-service-certificate-configmap_service-serving-certificate *** This bug has been marked as a duplicate of bug 1845188 ***