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