How to config Basic Auth with File-based Service Discovery?

[Ben Teitelbaum]

I'm confused about how to configure HTTP basic auth through the file-based service discovery mechanism.  Relabeling works to set the scheme and metrics_path in the target URL, but not the username or password. 

This is what I expected would work in the config file JSON, but no luck:

[

  {

    "targets":[

      "foo.com:9100"

    ],

    "labels":{

      "__scheme__":"https",

      "__metrics_path__":"/metrics",

      "__username__":"booyah",

      "__password__":"topsecret",

      "job":"bb395d48-a11a-4be9-9ace-a8f893db907c"

    }

  }

]

How can this be made to work?

-- ben

[Julien Pivotto]

Hello,

Basic auth can only be configured in the scrape configuration.

It is not possible to configure it in file_sd and it would expose the secrets in the UI.

--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/c827cb93-2d98-45b7-84eb-cce8eda7db20n%40googlegroups.com.

[Ben Teitelbaum]

We have a very dynamic setup. Having to dynamically update the scrape configuration when a target is added or removed seems very cludgy.

Why not fix the UI so that it doesn't expose secrets and doesn't cripple the file-based service discovery?

P.S. I just found https://github.com/prometheus/prometheus/issues/4026 which discusses this.

-- ben

[Julien Pivotto]

On 03 Feb 23:39, Ben Teitelbaum wrote:
> We have a very dynamic setup. Having to dynamically update the scrape
> configuration when a target is added or removed seems very cludgy.
>
> Why not fix the UI so that it doesn't expose secrets and doesn't cripple
> the file-based service discovery?
>
> P.S. I just found https://github.com/prometheus/prometheus/issues/4026
> which discusses this.

Hello,

I'd suggest using the same password. What would be the problem with
that?

If you wish more security you can also look at tls client certificates
but that would still be one per scrape config.

There is much more than just the UI ; you could use relabelling to set
these, so we would need to filter the original labels, the transformed
ones, etc.

> >> <https://groups.google.com/d/msgid/prometheus-users/c827cb93-2d98-45b7-84eb-cce8eda7db20n%40googlegroups.com?utm_medium=email&utm_source=footer>
> >> .

> >>
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CAHrnr0bDajzzZZZY6M1%3DKNGLyy-m%3D-Wt6RMVYX3Bj2XBaoe3TQ%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

[Ben Teitelbaum]

I'd suggest using the same password. What would be the problem with
that?

Proprietary data providers, different administrative control of upstream systems. Not realistic to assume one set of HTTP basic auth credentials across all targets.

 

There is much more than just the UI ; you could use relabelling to set
these, so we would need to filter the original labels, the transformed
ones, etc.

That makes sense. Thanks for explaining.

-- ben 

[Ben Kochie]

What would be useful is if the basic auth params were something you could apply with reliable configs. Similar to how __scheme__ and __metrics_path__ work.

There have been discussions about this, but I don't think there's a concrete issue for implementing it.

Maybe worth filing a new issue.

--

You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CAHrnr0bTOkNs4C%3DsN9LtdhwUbA4wjLyq89Ap56Y6hygg755J1w%40mail.gmail.com.

[Julien Pivotto]

Well, that would still raise the security question as the labels would
be available on the web interface.

> > <https://groups.google.com/d/msgid/prometheus-users/CAHrnr0bTOkNs4C%3DsN9LtdhwUbA4wjLyq89Ap56Y6hygg755J1w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .

> >
>
> --
> You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CABbyFmrrpbY3wvEAQ5yL%2BQ_tvDVTEgFsynPh5VoODSZ1uT3Tdw%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

[Ben Teitelbaum]

Instead of setting HTTP basic auth username and password as labels in the file discovery YAML or JSON, couldn't they be configured as a non-label settings, like this:

[
  {
    "targets":[
      "foo.com:9100"
    ],
    "basic_auth":{
      "username":"booyah",
      "password":"topsecret",      

    },
    "labels":{
      "__scheme__":"https",
      "__metrics_path__":"/metrics",

      "job":"bb395d48-a11a-4be9-9ace-a8f893db907c"
    }
  }
]

eliminating the possibility that secrets would leak through the relabelling process?

-- ben

[Ben Kochie]

That won't work for  other discovery methods.

We could add a new concept of "secret labels" that would be masked in the UI.