Feature request: override secret censoring during marshaling to YAML

[DuskEagle]

What did you do?

I am looking for a way to programmatically generate Alertmanager configurations. I imported github.com/prometheus/alertmanager/config into my project and used it to generate an Alertmanager config, which I then marshaled into a YAML string and wrote out to a Kubernetes ConfigMap.

What did you expect to see? What did you see instead?

I expected a working Alertmanager config, but all the API keys for my receivers had been marshaled into the string "<secret>". It would be great if there was a way to override this custom marshaling and get a working Alertmanager config with API keys and other secrets uncensored. They would still need to be censored by default, for places like the Alertmanager UI.

Other approaches

If secrets could be passed into the Alertmanager config using file locations, rather than directly as strings, then there would be no need to override the secret marhsaling behaviour. e.g.

slack_configs:
- api_url: /path/to/api_url

[simonpasquier]

It's not the first time this request is made but until now, the maintainers are reluctant to expose those types externally. See #1804 (comment) for the arguments.

[bobheadxi]

@simonpasquier would a package-level flag work? I can send a PR to enable something like:

config.MarshalSecrets = true
yaml.Marshal(c) // stuff gets outputted with secret

[roidelapluie]

The usecase is really not clear here.

[bobheadxi]

@roidelapluie for my specific case, we're trying to update Alertmanager configuration programatically (rather than by hand). The config package structs make this a lot easier, but unfortunately it is impossible to write updated configuration back to disk for Alertmanager to reload and use since secrets get replaced. Adding something like config.MarshalSecrets would allow anyone using the config package directly to write secrets when needed. This is very similar to the use-case described by @DuskEagle

[simonpasquier]

To repeat what Stuart said in an earlier discussion:

makes it much easier to accidentally expose secrets, and is a feature that would be better decided upon by the entire org (do we want to expose config types that can be used to generate a valid config?).

This is the most important point: we want consistency across all projects under the Prometheus organization and Alertmanager alone can't go a different path.

[roidelapluie]

After reconsidering, it seems that it may be reasonable for libraries to choose to participate in this, particularly as webhook URLs are being treated as secrets in next releases.