Support environment variables in config

[jhogendorn]

💡 Support environment variables in config

The configuration file is in essence a list of apprise uri's, which include secrets. I have dug through the docs a fair bit so forgive me if this is already possible, but it would be good if we could specify environment variables in the config for the secrets. Alternatively a way of specifying yaml variables or other interpolation so that a file can be built on demand and included that includes the secrets.

Theres envsubst as an approach but internal tool support would be good.

Another common approach is to have secrets in individual files, this would be more complicated to natively support.

ie

urls:
  - schema://$ACCESS_KEY/$ACCESS_SECRET/foo/bar/baz

🔨 Breaking Feature

This wouldnt break anything in terms of compatibility.

[caronc]

Per environment variable... This isn't really possible as there are so many tokens (or even people's passwords) the have $ in them.

A change like this could break many configurations.

Per having a secrets file, that's a good idea. The only thing is that you can chmod 600 .apprise and now it's a secret too. For Home Assistant the !secret works nicely because then you can share your configuration publicly. You would get the similar outcome with Apprise, but once the you park your secrets in other files, there isn't much of the main configuration left...? Apprise supports already an include statement which can be placed in the config (and subsequent ones included) which can pull from another file or web URL too. I'm not sure if this helps?

A similar request is here.

Thoughts?

[jhogendorn]

Yeah i see the issue with $ being in people secrets and having erroneous swaps.

An option may be to have a yaml object in the tree specifically for variables and then a syntax for using those variables elsewhere. its unlikely a user will both map a variable name and then have that variable name in the secret and not want it replaced. An alternative might be to support a secrets config file that can take strings, env vars or file paths, and can be used in the main file. Sort of like how the aws cli does it. Either approach would de-secret the config file enabling it to be shared, version controlled, etc.

Re files, in cicd and other infra systems its one of the common approaches. IE in Gitlab Secrets management its a flag whether to have the secret injected as an env var or as a temp file. So it creates a file per secret. The file per secret approach is arguably 'better', files have permissions, dont get dumped out in env dumps, can log access, can hold large amounts of data and dont need handling around special chars etc, are expected as files sometimes like ssh keys etc.

I agree that most of the config file at the moment is indeed just secret storage as it is. I could see a future where the config expands to support things like templates, defaults, etc. But even if the config is slim, theres value in separating implementation (uris) and data (secrets). As it is currently, the config file itself is essentially just one big secret.