amtool: passwords passed in the command line

[Julien Pivotto]

Hello -developers,

In the past and still today, we have asked exporters not to use secrets
on the command line.

There is a pull requests that wants to add secrets on the amtool command
line:
https://github.com/prometheus/alertmanager/pull/2764

and users requests to pass arbitrary http headers in amtool via the
command line too. In the same way, users want to add arbitraty secrets
in HTTP headers: https://github.com/prometheus/alertmanager/issues/2597

I am personally opposed to allow what we ask others not to do, but maybe
I am stubborn, so I am asking the developers community here what should
we do here?

My proposal was to introduce a HTTP client configuration file to amtool,
so we tackle the secret issue and enable all the other HTTP client
options easily (oauth2, bearer token, proxy_url, ...). The community was
not entirely keen on it:
https://github.com/prometheus/alertmanager/issues/2597#issuecomment-974144389

What do the large group of developers think about all this? Note that
the solution we chose here could/should be applied to promtool and
getool later.

Thanks!

--
Julien Pivotto
@roidelapluie

[Augustin Husson]

Hello,

I think having the http config file is a good idea and a safe one.

The fact users have a rotation in the credential used only means the client has to authenticate themself first to get a fresher session / token / credentials. Maybe it's more sophisticated than that, but from my understanding it shouldn't be.

Kubernetes is using a config file for it's kube client and it works nicely. The token used and stored in the file expires every 24h  and it's not so hard to have a fresher one.

Best regards,

Augustin.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen.

[Colin Douch]

I think the Kubernetes analogy is a good one. My only reservation (as in the GitHub thread above) is that any structure in an http config file would probably need tooling around parsing/generating them in situations where tokens rotate frequently. That's not a deal breaker (and I wholeheartedly agree that secrets in a bash history is a bad idea), but that maintenance burden is something to keep in mind.

Is there some form of established config file format that you would propose to use? Or would we be inventing something bespoke?

- Colin

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com.

[Julien Pivotto]

On 24 Nov 20:56, Colin Douch wrote:
> I think the Kubernetes analogy is a good one. My only reservation (as in
> the GitHub thread above) is that any structure in an http config file would
> probably need tooling around parsing/generating them in situations where
> tokens rotate frequently. That's not a deal breaker (and I wholeheartedly
> agree that secrets in a bash history is a bad idea), but that maintenance
> burden is something to keep in mind.
>
> Is there some form of established config file format that you would
> propose to use? Or would we be inventing something bespoke?

Yes, I would use alertmanager' http_config:
https://prometheus.io/docs/alerting/latest/configuration/#http_config

If we want headers support, we could extract
https://github.com/prometheus/prometheus/blob/5e746e4e88adfe44a69764e3ac99d2d01f2224db/storage/remote/client.go#L169

and have it in prometheus/common (to be added ad-hoc where needed, not by default in the http client)

> > https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com
> > <https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAGb-_uX7LM16nPeKwYGzq%2BHUiJ-j-fH-ovtFT4%2B7cDjTVezPdQ%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

[Colin Douch]

> Yes, I would use alertmanager' http_config:

Ah cool. That works - I think that covers 99% of use cases, so full header support can come later IMO

- Colin

[Ben Kochie]

There are lots of ways to easily inject secrets into configs.

Adding secrets/headers via config file is the safest way.

While I'm all for allowing sharp edges in tools if they're not default, I'm strongly against having known unsafe things like secrets on the command line.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com.

[Matthias Rampke]

I take a less hard line on that … I think it's good not to accept secrets on the command line, but I think we should not categorically exclude generic features (like headers on the command line) because someone might put secrets there.

I don't have a final opinion whether we should add more than the config file in this case, but a feedback I hear a lot from users is that having to generate files left and right is challenging in post-configuration-management systems (think "I want to run this as a one-off job on Kubernetes"). If our stance that secrets only go in files causes someone to commit that file to source control, we've verschlimmbessert the overall situation.

/MR

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABbyFmpuNnWrT2H6o2Vkpuuvhsa0mJ%2B5MKapUvhs2_0Vs_FZ4w%40mail.gmail.com.

[Julien Pivotto]

What usecase for amtool would not involve authorization or authentication? I don't think there are.

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

[Matthias Rampke]

That's fair, I only ask that we consider use cases when they come up :)

/MR

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAFJ6V0qeOtM4f4HN4%2BMBUe%2BxicNnDQBnBWZxhGXwUGGdpxz41Q%40mail.gmail.com.