feat: Added support for Docker secrets #690
Conversation
If an attacker can run The major benefit I see here actually is to put your secrets in a separate file that's not in the docker-compose file. |
|
It depends on how you initialize the secrets. Yes, at minimum you've moved your secrets to a different file that can be owned by some other user and not readable however you can also setup secrets from other sources. I want to not have my secrets live on disk and in an unencrypted form. That's completely nullified if someone just needs to then have access to the Docker daemon and they can now see anything that I've configured. |
| t.Errorf("unable to write secret to temporary file: %s", err.Error()) | ||
| } | ||
|
|
||
| os.Setenv("GATUS_TestExpandingOfFileEnvironmentVariables_FILE", tempFile.Name()) |
There was a problem hiding this comment.
can you unset the env var after this test using defer? Just to prevent surprises.
| } | ||
|
|
||
| func TestExpandingOfFileEnvironmentVariablesMissingFile(t *testing.T) { | ||
| os.Setenv("GATUS_TestExpandingOfFileEnvironmentVariables_FILE", "TestExpandingOfFileEnvironmentVariablesMissingFile.txt") |
| os.Setenv("GATUS_TestExpandingOfFileEnvironmentVariables_FILE", tempFile.Name()) | ||
| os.Setenv("GATUS_TestExpandingOfFileEnvironmentVariables", otherSecretValue) |
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #690 +/- ##
==========================================
+ Coverage 78.62% 80.75% +2.12%
==========================================
Files 58 59 +1
Lines 4759 4094 -665
==========================================
- Hits 3742 3306 -436
+ Misses 831 596 -235
- Partials 186 192 +6 ☔ View full report in Codecov by Sentry. |
This adds the ability to use [Docker secrets](https://docs.docker.com/compose/use-secrets/) in configuration files. In Docker this is done by creating a secret resource, adding that secret to the container when you're starting it, and specifying an environment variable that has the `_FILE` suffix. The environment variable should point to the file which contains the secret (`/run/secrets/<secret-name>`). Typically Docker images are setup so that they will try and find any environment variables that end in `_FILE` and set new environment variables with the same name minus the `_FILE` suffix in the running process. This is beneficial since environment variables that are set by the user when creating the container are visible to anyone who is able to run `docker container inspect <container>` on the host. For secrets this could be really damaging and leak sensitive information. Instead it is recommended to use Docker secrets. Because Gatus uses the `scratch` base image I wasn't able to just use a Bash script to convert the secret file path into a normal environment variable like many other images do. Instead I opted to just modify the configuration logic so that it checks the environment variable name and changes its behavior based on that. This seems to work well enough. As far as error handling, I opted _not_ to crash the service when it's unable to read the secret file and instead just pretend its a normal environment variable and return an empty string. This follows the conventions of the rest of the configuration handling and leaves the error reporting to the configuration validation. I've also updated the readme to mention this feature with a link to an example.
|
@TwiN I've addressed your comments, thanks for reviewing! |
Summary
This adds the ability to use Docker secrets in configuration files. In Docker this is done by creating a secret resource, adding that secret to the container when you're starting it, and specifying an environment variable that has the
_FILEsuffix. The environment variable should point to the file which contains the secret (/run/secrets/<secret-name>).Typically Docker images are setup so that they will try and find any environment variables that end in
_FILEand set new environment variables with the same name minus the_FILEsuffix in the running process. This is beneficial since environment variables that are set by the user when creating the container are visible to anyone who is able to rundocker container inspect <container>on the host. For secrets this could be really damaging and leak sensitive information. Instead it is recommended to use Docker secrets.Because Gatus uses the
scratchbase image I wasn't able to just use a Bash script to convert the secret file path into a normal environment variable like many other images do. Instead I opted to just modify the configuration logic so that it checks the environment variable name and changes its behavior based on that. This seems to work well enough.As far as error handling, I opted not to crash the service when it's unable to read the secret file and instead just pretend its a normal environment variable and return an empty string. This follows the conventions of the rest of the configuration handling and leaves the error reporting to the configuration validation.
I've also updated the readme to mention this feature with a link to an example.
Checklist
README.md, if applicable.