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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >>> 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 [email protected]. >>>> 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 [email protected]. >>> 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&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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/CABbyFmpuNnWrT2H6o2Vkpuuvhsa0mJ%2B5MKapUvhs2_0Vs_FZ4w%40mail.gmail.com >> <https://groups.google.com/d/msgid/prometheus-developers/CABbyFmpuNnWrT2H6o2Vkpuuvhsa0mJ%2B5MKapUvhs2_0Vs_FZ4w%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAMV%3D_gbcesE1_Et0kXNLaj7Bz0BhCMhMMm9kXyb8Za17SaJx8g%40mail.gmail.com > <https://groups.google.com/d/msgid/prometheus-developers/CAMV%3D_gbcesE1_Et0kXNLaj7Bz0BhCMhMMm9kXyb8Za17SaJx8g%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAFJ6V0qeOtM4f4HN4%2BMBUe%2BxicNnDQBnBWZxhGXwUGGdpxz41Q%40mail.gmail.com.
