You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Prometheus Operator always fetches the Alertmanager configuration from a Kubernetes Secret (configSecret key from the alertmanagerSpec).
I suppose the configuration was fetched from a Secret because traditionally, password, API keys/or tokens, etc. were directly part of Alertmanager's configuration file.
Since a few releases already, Alertmanager supports reading secrets from external file, rendering the main configuration file secret-free for most of the secrets, see: prometheus/alertmanager#2498
It would be nice if, instead of storing the whole Alertmanager configuration into a Secret, to be able to store it in a normal ConfigMap and reference external secrets through the new _file options.
Why do we need it?
This would cleanly separate the non-secret configuration part from the really secret configuration parts, and would make the main configuration file easier to manipulate through normal Kubernetes ConfigMap accesss, without leaking secrets.
One pitfall if we were to implement this is that users may start putting sensitive data in the ConfigMap. At least the secret approach makes it obvious that it has security implications.
A better approach would be to promote the usage of the new spec.alertmanagerConfiguration field in the Alertmanager CRD like described here.
What is missing?
The Prometheus Operator always fetches the Alertmanager configuration from a Kubernetes Secret (
configSecret
key from thealertmanagerSpec
).I suppose the configuration was fetched from a Secret because traditionally, password, API keys/or tokens, etc. were directly part of Alertmanager's configuration file.
Since a few releases already, Alertmanager supports reading secrets from external file, rendering the main configuration file secret-free for most of the secrets, see: prometheus/alertmanager#2498
It would be nice if, instead of storing the whole Alertmanager configuration into a Secret, to be able to store it in a normal ConfigMap and reference external secrets through the new
_file
options.Why do we need it?
This would cleanly separate the non-secret configuration part from the really secret configuration parts, and would make the main configuration file easier to manipulate through normal Kubernetes ConfigMap accesss, without leaking secrets.
Environment
Anything else we need to know?:
The text was updated successfully, but these errors were encountered: