[Feature] Specify sensitive config values via environment variables

[vanchaxy]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

Currently, config can be provided via UI or json file.

Some config values, like oauth.clientSecret or smtp.password are sensitive. It would be nice to provide these values using environment variables. That will be useful for declarative Immich setup using gitops.

Possible implementations:

1. Allow templating inside immich.json. E.g.

"oauth": {
    ...,
   "clientSecret": "${IMMICH_OAUTH_CLIENT_SECRET}",
    ...,
},

Immich then should replace clientSecret with the value of IMMICH_OAUTH_CLIENT_SECRET env.

2. Allow keys overriding using envs. E.g. IMMICH_CONFIG_oauth_clientSecret env will override oauth.clientSecret key.

The current workaround is templating externally, e.g. with init container before Immich starts or using secrets manager templating capabilities.

Platform

• Server
• Web
• Mobile

[bo0tzz]

The workarounds you suggest are already perfectly serviceable approaches, no?

[vanchaxy]

I wouldn't call it perfect as it adds one more extra step/container in the deployment, so one more step can fail and need support. Not all secret managers support templating, so it also depends on your setup. I'd like to see first-class secrets support by Immich itself.

[tecosaur]

It can also be quite awkward, for example I'm currently trying to deploy immich via NixOS and I can't use the services.immich.settings method because templating this is incredibly awkward. I could start encrypting the file in Git, but it would be vastly preferable if something like clientSecretFile could be used instead.

[bo0tzz]

We discussed this in the team and decided against adding support in Immich, since there are already plenty of good approaches to storing config as a secret or templating it out with things like envsubst.

[vanchaxy]

@bo0tzz Thanks for the answer. Can you please clarify how feature requests for Immich work?

Does a closed issue mean that the community can't vote on a feature and the team won't accept external contributions for it?

I can see other options for this without adding support to Immich:
a) support in the official helm chart (e.g. envsubst as an optional init container);
b) adding official documentation about passing secrets to config;
c) adding a community guide for it.

I can contribute to any of these. What option is acceptable for the team?

[bo0tzz]

A closed request means we're not planning to add official support for this. Of course you're still free to discuss in here etc. Note that at this stage we hardly consider feature votes in any case, as our roadmap is long and already pretty clear.

The first two options would still amount to some degree of official support, but a community guide is always welcome.

[tecosaur]

For the record, this is what I've ended up doing: https://code.tecosaur.net/tec/golgi/src/commit/e78515dd19d4e70de85ad6939834a4d1e426eada/modules/immich.nix#L83-L94

It's a bit of a hack, but it works.

[Eoghanmc22]

I dont understand why passing via env vars is supported for database and redis credentials but not for the OAUTH secrets

[bo0tzz]

Because those values are at different levels. DB and redis are required for Immich to start up, OAuth isn't.

[diogotcorreia]

If anyone is trying to figure out how to do this with Nix, I did a workaround here:
diogotcorreia/dotfiles@d6ff49b

Proper support from Immich side would still be very much desirable :)
Thanks for the awesome project!

[Deliganli]

If you are using sops with nixos, I have an example how to do it as well;
https://gist.github.com/Deliganli/554dcc0d05fbd859fb768d2ed2c717c7

Downside of this is, we circumvent code in upstream nixpkgs repo. There may be some smart useful bits, where it is looking to config.services.immich.settings and doing things depending on the values. Since we are leaving it as null and sideloading our own config, it can't be used.

There is no such functionality in the upstream yet, but there may be in the future.

[cterence]

Here's a way to solve the problem with Kubernetes. I use an init container to run envsubst on the config file from the readonly configmap. It outputs the result in an emptyDir volume mounted by both init and main containers. The "templated" configmap is the one I provide to immich main container with the IMMICH_CONFIG_FILE env var.

[Lau-r-a]

Funny the maintainers call this a "already perfectly serviceable approaches". Thats hardly the case...

[cterence]

Yeah... I had to scratch my head for a while to get this one working.

[2o1o0]

Same here, it is the only chart (40 deployed right now) where I cannot reference a k8s secret directly from values, which is a bit annoying. I've checked your solution @cterence (btw well done on the argocd template!) but it would make life so much easier to have this single secret to be fed from an env var.