Inject cluster CA into operator pod on openshift

[marpears]

Describe the bug
5.13.0 introduces a change which by default enforces TLS when communicating with external Grafanas.

When following the docs it states to create a kubernetes.io/tls secret with the ca.crt. In my case I only need to specify a ca bundle and there is no client TLS verification required. Creating a kubernetes.io/tls secret with blank tls.crt and tls.key causes an error in the admission webhook and also leads to errors in the grafana operator which complains about the empty tls.crt and tls.key.

A secret of type opaque was created instead which contains the ca bundle under key ca.crt, which worked. But since this is just a CA bundle, why can't this be stored in a ConfigMap? This way, the mechanism described in the OCP docs could be used to create a ConfigMap containing the CA bundle and be referenced under something like spec.external.tls.caBundle.name in the Grafana CR

Version
5.13.0

[marpears]

Could the Grafana operator on Openshift create the config map using the the mechanism described in the OCP docs and mount it into the grafana-operator-controller-manager-v5 pod?

That way, the change to enforce TLS would be less likely to be a breaking change if the cluster has been set up with a user-ca-bundle and no modifications to any Grafana CRs would be required.

[theSuess]

Could the Grafana operator on Openshift create the config map using the the mechanism described in the OCP docs and mount it into the grafana-operator-controller-manager-v5 pod?

This is a great idea! I'll rephrase this issue and will try to implement it for the next release