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, <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/CAGb-_uX7LM16nPeKwYGzq%2BHUiJ-j-fH-ovtFT4%2B7cDjTVezPdQ%40mail.gmail.com.
