Allow loading all secrets via separate URI

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD

https://gitea.com

MIT License

43.9k stars 5.38k forks source link

Allow loading all secrets via separate URI #16603

Open clarfonthey opened 3 years ago

clarfonthey commented 3 years ago

Right now, the security.INTERNAL_TOKEN_URI option allows loading the security.INTERNAL_TOKEN parameter via a separate file. It would be nice if we could extend this to the other secrets in app.ini as well.

The variables I found that could use this:

[ ] oauth.JWT_SECRET (currently, JWT_SIGNING_PRIVATE_KEY_FILE is used for RSA and ECDSA, but a separate file cannot be used for HMAC)
[ ] server.LFS_JWT_SECRET
[x] security.SECRET_KEY (#19663)
[ ] service.{RE,H}CAPTCHA_{SECRET,SITEKEY}
[ ] storage.MINIO_{ACCESS_KEY_ID,SECRET_ACCESS_KEY} (and similar sections like lfs and attachment)

Note that this is related to (but not the same as) #4860.

techknowlogick commented 3 years ago

Indeed, we'd be open for a PR for this, as it allows for secrets to be passed via docker/kubernetes secrets etc...

cc: @justusbunsi

justusbunsi commented 3 years ago

I guess it wouldn't be much to do. Should be similar to what was done here. https://github.com/go-gitea/gitea/blob/main/modules/setting/setting.go#L1028

clarfonthey commented 3 years ago

Honestly, the biggest (potential) issue is how the minio/captcha secrets should be loaded, since it would make sense in those cases to group together the credential pair into one file. But yeah, the code for the internal token should mostly cover all the cases we want.

Bonus points if you can make gitea run the various generate commands for non-existent files before running if they don't exist.

clarfonthey commented 2 years ago

Updated issue description to be a checklist for the settings that are converted over, since #19663 implements this for SECRET_KEY.