Re: [prometheus-developers] amtool: passwords passed in the command line

[Matthias Rampke]

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

/MR

On Wed, Dec 1, 2021 at 12:38 PM Julien Pivotto 
wrote:

> What usecase for amtool would not involve authorization or authentication?
> I don't think there are.
>
> Le mer. 1 déc. 2021, 09:21, Matthias Rampke  a
> écrit :
>
>> 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
>>
>>
>> On Tue, Nov 30, 2021 at 9:09 AM Ben Kochie  wrote:
>>
>>> 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.
>>>
>>> On Tue, Nov 23, 2021 at 5:38 PM Augustin Husson <
>>> husson.augus...@gmail.com> wrote:
>>>
 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.

 Le mar. 23 nov. 2021 à 17:15, Julien Pivotto <
 roidelapl...@prometheus.io> a écrit :

> 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
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
> .
>
 --
 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-developers+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com
 
 .

>>> --
>>> 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-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> 

Re: [prometheus-developers] amtool: passwords passed in the command line

[Julien Pivotto]

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

Le mer. 1 déc. 2021, 09:21, Matthias Rampke  a
écrit :

> 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
>
>
> On Tue, Nov 30, 2021 at 9:09 AM Ben Kochie  wrote:
>
>> 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.
>>
>> On Tue, Nov 23, 2021 at 5:38 PM Augustin Husson <
>> husson.augus...@gmail.com> wrote:
>>
>>> 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.
>>>
>>> Le mar. 23 nov. 2021 à 17:15, Julien Pivotto 
>>> a écrit :
>>>
 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

 --
 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-developers+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
 .

>>> --
>>> 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-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/CABbyFmpuNnWrT2H6o2Vkpuuvhsa0mJ%2B5MKapUvhs2_0Vs_FZ4w%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus 

Re: [prometheus-developers] amtool: passwords passed in the command line

[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


On Tue, Nov 30, 2021 at 9:09 AM Ben Kochie  wrote:

> 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.
>
> On Tue, Nov 23, 2021 at 5:38 PM Augustin Husson 
> wrote:
>
>> 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.
>>
>> Le mar. 23 nov. 2021 à 17:15, Julien Pivotto 
>> a écrit :
>>
>>> 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
>>>
>>> --
>>> 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-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
>>> .
>>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com
>> 
>> .
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CABbyFmpuNnWrT2H6o2Vkpuuvhsa0mJ%2B5MKapUvhs2_0Vs_FZ4w%40mail.gmail.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [prometheus-developers] amtool: passwords passed in the command line

[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.

On Tue, Nov 23, 2021 at 5:38 PM Augustin Husson 
wrote:

> 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.
>
> Le mar. 23 nov. 2021 à 17:15, Julien Pivotto 
> a écrit :
>
>> 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
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
>> .
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CABbyFmpuNnWrT2H6o2Vkpuuvhsa0mJ%2B5MKapUvhs2_0Vs_FZ4w%40mail.gmail.com.

Re: [prometheus-developers] amtool: passwords passed in the command line

[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

On Wed, Nov 24, 2021 at 9:18 PM Julien Pivotto 
wrote:

> 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)
>
> >
> > - Colin
> >
> > On Wed, 24 Nov 2021, 3:38 am Augustin Husson,  >
> > wrote:
> >
> > > 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.
> > >
> > > Le mar. 23 nov. 2021 à 17:15, Julien Pivotto <
> roidelapl...@prometheus.io>
> > > a écrit :
> > >
> > >> 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
> > >>
> > >> --
> > >> 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-developers+unsubscr...@googlegroups.com.
> > >> To view this discussion on the web visit
> > >>
> https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
> > >> .
> > >>
> > > --
> > > 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-developers+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> > >
> 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_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-developers+unsubscr...@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
>

-- 
You 

Re: [prometheus-developers] amtool: passwords passed in the command line

[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)

> 
> - Colin
> 
> On Wed, 24 Nov 2021, 3:38 am Augustin Husson, 
> wrote:
> 
> > 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.
> >
> > Le mar. 23 nov. 2021 à 17:15, Julien Pivotto 
> > a écrit :
> >
> >> 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
> >>
> >> --
> >> 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-developers+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
> >> .
> >>
> > --
> > 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-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com
> > 
> > .
> >
> 
> -- 
> 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-developers+unsubscr...@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

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/20211124101828.GA286681%40hydrogen.

Re: [prometheus-developers] amtool: passwords passed in the command line

[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

On Wed, 24 Nov 2021, 3:38 am Augustin Husson, 
wrote:

> 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.
>
> Le mar. 23 nov. 2021 à 17:15, Julien Pivotto 
> a écrit :
>
>> 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
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
>> .
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com
> 
> .
>

-- 
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-developers+unsubscr...@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.

Re: [prometheus-developers] amtool: passwords passed in the command line

[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.

Le mar. 23 nov. 2021 à 17:15, Julien Pivotto  a
écrit :

> 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
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20211123161546.GA696401%40hydrogen
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAOJizGcb45MwjCj3Bd6_gt9ZatS%2Bnbw%2B1QvjD8wbNdfR77eo%3DQ%40mail.gmail.com.