Prometheus metrics endpoint exposes credentials over plaintext HTTP #94

New Issue

dannygroenewegen · 2026-03-13T12:28:58Z

dannygroenewegen commented

2026-03-13 12:28:58 +00:00

The metrics endpoint is currently configured on a dedicated entrypoint on port 8082 with basicauth middleware. Because this entrypoint has no TLS, basic authentication credentials are transmitted in cleartext over HTTP. This is particularly relevant in multi-host setups where metrics are scraped across hosts.

A solution would be to expose the metrics endpoint through a HTTPS router using manualRouting with these snippets:

metrics:
  prometheus:
    entryPoint: web-secure
    manualRouting: true
    addRoutersLabels: true
    addServicesLabels: true

http:
  routers:
    traefik-metrics:
      rule: "Host(`${PROMETHEUS_METRICS_HOSTNAME`)"
      entrypoints:
        - web-secure
      tls:
        certResolver: ${LETS_ENCRYPT_ENV}
      middlewares:
        - basicauth@file
      service: prometheus@internal

I'm happy to open a PR for this. Two approaches are possible and I'd like input on which direction to take:

Non-breaking: add a new secure metrics configuration alongside the existing one, so current installations are unaffected. Users can opt in to the secure setup.
Breaking: replace the current plaintext configuration with the secure approach. This would require users to update their setup (both Traefik .env and hostname configuration in monitoring-ng scrape config).

I lean toward option 2, given that the current configuration transmits credentials in cleartext. I think defaults should be secure, even if that means a breaking change.

The metrics endpoint is currently configured on a dedicated entrypoint on port 8082 with basicauth middleware. Because this entrypoint has no TLS, basic authentication credentials are transmitted in cleartext over HTTP. This is particularly relevant in multi-host setups where metrics are scraped across hosts. A solution would be to expose the metrics endpoint through a HTTPS router using `manualRouting` with these snippets: ```yaml metrics: prometheus: entryPoint: web-secure manualRouting: true addRoutersLabels: true addServicesLabels: true ``` ```yaml http: routers: traefik-metrics: rule: "Host(`${PROMETHEUS_METRICS_HOSTNAME`)" entrypoints: - web-secure tls: certResolver: ${LETS_ENCRYPT_ENV} middlewares: - basicauth@file service: prometheus@internal ``` I'm happy to open a PR for this. Two approaches are possible and I'd like input on which direction to take: 1. Non-breaking: add a new secure metrics configuration alongside the existing one, so current installations are unaffected. Users can opt in to the secure setup. 2. Breaking: replace the current plaintext configuration with the secure approach. This would require users to update their setup (both Traefik .env and hostname configuration in monitoring-ng scrape config). I lean toward option 2, given that the current configuration transmits credentials in cleartext. I think defaults should be secure, even if that means a breaking change.

👀 1

decentral1se commented

2026-03-13 14:41:43 +00:00

Oh shiet, good catch. I'm happy to see a PR for option 2. I don't quite understand the config implications and also this is then connected to monitoring-ng? If you can provide links to the specific configuration lines in the recipes, that would help.

Oh shiet, good catch. I'm happy to see a PR for option 2. I don't quite understand the config implications and also this is then connected to `monitoring-ng`? If you can provide links to the specific configuration lines in the recipes, that would help.

👍 1

stevensting commented

2026-03-19 07:57:36 +00:00

Thanks for reporting. I would also prefer solution 2, and if we do it right it isn't even that breaking I guess:

make modifications to traefik recipe as outline above
make modifications to monitoring-ng as outlined above
at the same time release new versions of traefik and monitoring-ng
tell people in the releasenotes that they also need to update the other app
all people need to do is update both at the same time to prevent stuff from breaking

some more hints:

I did not need to do anything special in the scrape config for https. I think prometheus just accepts being rerouted to https
I added a https endpoint for prometheus monitoring to backup bot two yesterday, the implementation is probably the quiet similar: https://git.coopcloud.tech/coop-cloud/backup-bot-two/pulls/84/files

@p4u1 did I overlook something?

Thanks for reporting. I would also prefer solution 2, and if we do it right it isn't even that breaking I guess: - make modifications to traefik recipe as outline above - make modifications to monitoring-ng as outlined above - at the same time release new versions of traefik and monitoring-ng - tell people in the releasenotes that they also need to update the other app - all people need to do is update both at the same time to prevent stuff from breaking some more hints: - I did not need to do anything special in the scrape config for https. I think prometheus just accepts being rerouted to https - I added a https endpoint for prometheus monitoring to backup bot two yesterday, the implementation is probably the quiet similar: https://git.coopcloud.tech/coop-cloud/backup-bot-two/pulls/84/files @p4u1 did I overlook something?

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/traefik#94