Hi Prometheans, Container orchestration platforms like Kubernetes offer secrets management. K8s provides those secrets directly to the Kubelet, or via environment variables, or as files in a volume that containers can mount, see https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets for details.
Good arguments have been made why secrets in environment variables are problematic. In the Prometheus ecosystem, we have mostly converged on using files in the scenario described here. That works just fine for the password of HTTP basic auth, the bearer token, TLS certificates, and probably more. However, there are a bunch of secrets in config files (in particular for Prometheus itself and for the Alertmanager) that _must_ be provided in the config file itself. (Search for `<secret>` in the documentation of a config file to find all secrets.) If you want to leverage the K8s secrets management for those, you have to jump through hoops, i.e. set up an init container that creates a config on the fly before starting the actual Prometheus or Alertmanager binary. My inner minister for consistency tells me we should either allow all secrets to be provided in a file or none. My inner minister for user experience tells me we can hardly make users jump through those hoops for the secrets where we currently allow files. So what do you think about generally providing a `xxx_file: <string>` config option where we currently just allow `xxx: <secret>`? There are a lot of those, but maybe it's the way to go? -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] bjo...@rabenste.in -- 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/20210218144952.GF2747%40jahnn.
