goharbor / harbor-helm

The helm chart to deploy Harbor
Apache License 2.0
1.18k stars 760 forks source link

ServiceMonitor scrapping failed if internal TLS is activated #1828

Open baaaaast opened 2 weeks ago

baaaaast commented 2 weeks ago

If we activate the auto cert generation with :

internalTLS:
    enabled: true
    certSource: "auto"

My prometheus service fails to scrap the https-metrics port because it doesn't have the ca bundle used to generate the certificate.

I'd like to be able to configure the tlsConfig part of the ServiceMonitor's endpoint : https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#monitoring.coreos.com/v1.TLSConfig

Can I do a PR ?

reasonerjt commented 1 week ago

@baaaaast Thanks for writing it up. I think this is a valid issue. IMO ideally we wanna make sure in the tlgConfig it trusts the CA that signs the internal cert. Is that possible?

baaaaast commented 1 week ago

Yes @reasonerjt I think it's possible by setting something like :

kind: ServiceMonitor
...
spec:
  endpoints:
  - honorLabels: true
    port: https-metrics
    tlsConfig:
      ca: the_secret_name

It all depends on whether the certificate generation is automatic, manual or based on a secret. I just thought I could configure tlsConfig in a completely free way like :

metrics-svcmon.yaml example

spec:
  jobLabel: app.kubernetes.io/name
  endpoints:
  - port:  {{ template "harbor.metricsPortName" . }}
    {{- if .Values.metrics.serviceMonitor.interval }}
    interval: {{ .Values.metrics.serviceMonitor.interval }}
    {{- end }}
    honorLabels: true
...
{{- if .Values.metrics.serviceMonitor.tlsConfig }}
    tlsConfig:
{{ toYaml .Values.metrics.serviceMonitor.tlsConfig | indent 4 }}
{{- end }}

Besides, I've decided to give up enabling internal tls as long as the services aren't able to reload the TLS secret if it's changed. This static aspect is too restrictive for me to use with certmanager. I don't need it anymore for the moment. Thank you