redhat-cop/resource-locker-operator

ServiceMonitor: wrong caFile path

Obirah opened this issue · 4 comments

The caFile in the ServiceMonitor for Prometheus needs to be updated.

Old value: /etc/prometheus/configmaps/serving-certs-ca-bundle/service-ca.crt

New value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

With the old value, Prometheus will throw the following error error creating HTTP client: unable to load specified CA cert /etc/prometheus/configmaps/serving-certs-ca-bundle/service-ca.crt: open /etc/prometheus/configmaps/serving-certs-ca-bundle/service-ca.crt: no such file or directory

thanks, which cluster are you running on (distribution and version)?

Amazon EKS (Kubernetes v1.21) and Prometheus v2.28.1.

I see now. So you are deploying via helm on EKS. That service-ca.crt exists only in OpenShift. We don't test your scenario very well.
Does it work if you set it to /var/run/secrets/kubernetes.io/serviceaccount/ca.crt?
I would expect other things to be broken.
Also if you are starring to use this operator for the patch feature, I recommend using the new patch-operator (https://github.com/redhat-cop/patch-operator) . You would probably have the same issue there, but the new operator has more features.

Yes, it works with /var/run/secrets/kubernetes.io/serviceaccount/ca.crt. To be honest, so far I haven't experienced any big problems with the operator on EKS as we're doing pretty simple patching with it.

The only thing I had to workaround is that OpenShift has the Service annotation for its SSL certificate and I needed to create my own little piece of automation to compensate for that.

I'll take a look at the patch operator, thank you. However, it will take a bit to migrate our GitOps tooling to it.

Back to the original problem: wouldn't it make sense to leave your OpenShift value for the cert as sane default but simply make it overridable?