feat(oidc): integrate optional secret loading from files

[tboerger]

Thanks for this great piece of software. I am running Semaphore on Kubernetes and I would like to load the secret values for OIDC from secrets. Since secrets could be mounted as files it would be great to reference client_id and client_secret by files.

It's entirely compatible to the current behavior, it's simply loading the values from files if the attributes are defined.

[hmoffatt]

I like this solution. I would like to keep my config.json and docker-compose.yml in git, but I don't want to check in the oidc secret.

[tboerger]

@fiftin would be great if you could take a look at this. I think it is a quite simple solution :)

[tboerger]

@fiftin it would be great to get at least some feedback what needs to be changed to get this rolling. I can see various other Prs are getting merged while some not getting any response at all.

[fiftin]

@tboerger, @hmoffatt Where you store database credentials? Why this solution should be available only for OIDC?

Currently database creds and encryption keys can be passed via environment variables. May be we should do this for OIDC too?

[tboerger]

This behavior could be added to other places as well, but I have just introduced it for OIDC as the OIDC providers can't be configured via environment variables. If it would be possible based on environment variables it would be already a good thing but I don't wanted to open that can of worms as a first contribution.

Beside that it's not available as environment variables it would also make it possible to properly use secret files within docker or kubernetes which would be todays best practice. Same applies to installations on Nix/NixOS where secrets are always sourced from files within /run/secrets.

[tboerger]

@fiftin if you are open for change I could prepare a PR which introduces https://github.com/jlevesy/envconfig?tab=readme-ov-file#array-an-slices where EVERY config value could be added based on environment variables. That would also shift the usage of the reflection within the util package to the library. Benefit is that any future config variable are automatically available via environment variables even if they are arrays or maps.

[fiftin]

@tboerger thank you for your contribution ;)

[tboerger]

You are welcome, thank you for this project. What do you think about the env variable integration mentioned above?