Splitting secrets from configuration

[bpasson]

Describe the feature request

At the moment Gatus uses a single configuration file for all configuration as far as I can see. When using Kubernetes as platform and ArgoCD with GitOps e.g I now have to put secrets in git. That is a big security issue.

I would like to be able to specify multiple configuration files which are merged based upon a specified priority rank in the config file. This way I can source the secrets from a different place.

Why do you personally want this feature to be implemented?

I would like to have this feature to keep secrets secret and out of GitOps.

How long have you been using this project?

For about 5 hours, as a replacement for Uptime Kuma due to the fact I can use OIDC here.

Additional information

No response

[PythonGermany]

There is a section about it in the readme, not sure if it helps, but it's definitely not limited to a single config file:

gatus/README.md

Lines 226 to 233 in 1df0801

	You can specify a custom path by setting the `GATUS_CONFIG_PATH` environment variable.
	If `GATUS_CONFIG_PATH` points to a directory, all `*.yaml` and `*.yml` files inside said directory and its
	subdirectories are merged like so:
	- All maps/objects are deep merged (i.e. you could define `alerting.slack` in one file and `alerting.pagerduty` in another file)
	- All slices/arrays are appended (i.e. you can define `endpoints` in multiple files and each endpoint will be added to the final list of endpoints)
	- Parameters with a primitive value (e.g. `metrics`, `alerting.slack.webhook-url`, etc.) may only be defined once to forcefully avoid any ambiguity
	- To clarify, this also means that you could not define `alerting.slack.webhook-url` in two files with different values. All files are merged into one before they are processed. This is by design.

[bpasson]

I will have to give that a go, I missed that completely. So much documentation.

[bpasson]

I have refactored my deployment to now have two different files. It works, but I do need to be very careful with the merging rules. I'd still like to request a priority maker for each file to make it easier to find merge issues. Highest priority always wins. Don't know if that is an easy fix or not, my go skills are not that good sadly.

[PythonGermany]

I'm not sure I quite understand the concept of how merging with priority will make it easier than without.

I've thought about the issue of secrets in the config file and searched for related issues in this repo. There was one where it was suggested to read config values from external files to separate secrets. Maybe the feedback there helps: #1399 (comment)

[bpasson]

The idea with the priority is to make it more predictable on how the merging is done and add the possibility to overwrite configuration from files with a higher priority. Now you can define a key just a single time. If you layer it with priority you can e.g. have a very basic default configuration on prio 1 and then keep layering on top of it replacing keys and values where needed.

Have look at https://smallrye.io/smallrye-config/Latest/config/getting-started/ they have a similar construct using ordinal.