glanceapp
Docker secrets
Description
with use of env variables in custom-api widges it would be more secure to have access to docker secrets. if a tag of VAR__FILE: apikey is used in the yaml it should be extracted from /run/secrets/apikey
Should be easy enough to add.
if a tag of VAR__FILE: apikey is used in the yaml
I'm not entirely sure what you mean by this, we currently use ${VARIABLE} for environment variables, the syntax for secrets could be something like $${apiKey} and you'd also be able to use it anywhere in the config.
in the docker-compose you can add docker secrets. yeah if you use a double dollar sign it means it should read from the file in /run/secrets/VAR. This prevents passwords and other sensitive data in your compose file when using docker specifically.
I am also interested in this feature.
How it often works in other projects is:
If any environment variable is used, instead of resolving it directly, it first looks if the same environment variable with _FILE appended to its name exists.
If it does, assume its content is a file path, and use the contents of that file.
If not, then try to resolve the originally stated environment variable.
In the example above, that would mean exposing the variable app_API_KEY_FILE: /run/secrets/app_api but in your template still use app_API_KEY.
Benefits are:
- your secrets aren't readable by other users on the system
- you don't need to change templates depending on the user using a secret or not
- path to secrets are decoupled from variable names
Downsides:
- for every environment variable used you are always checking for the existence of another variable too
- can't use it for variables that already end in
_FILE(but those tend to be files and not be secrets anyway) - might introduce async behavior in places that previously was fully synchronous
I think I understand the behavior you're trying to describe, however I'm leaning more towards the explicitness of using ${ENV_VARIABLE} only for environment variables and $${some_secret} to specifically load the content of files from /run/secrets/some_secret. It just makes it easier to document and less likely for someone to get into trouble if their environment variable ends with _FILE in cases where they may want to store a path to a file to be passed to a property and not with the intent of loading the contents of that file.
Would you still look at the environment variable to find the file path for people pointing to a non secret config file our outside of docker? Or directly resolve the name to a file in /run/secrets/ for docker secrets only?
Either way works for me since I'm going to keep running it in a container for the foreseeable future. But it makes a lot of sense to me to be explicit in the behavior like you mentioned.
Thanks for taking this up, I appreciate it!
Would you still look at the environment variable to find the file path for people pointing to a non secret config file our outside of docker? Or directly resolve the name to a file in /run/secrets/ for docker secrets only?
More so the latter, as I'm not familiar with other use cases where loading the contents of a file would be better than using an ENV. If there are any, then something like this might be even better and leave room for other potential ways to load values:
# directly loads the contents of /run/secrets/api_key
password: ${secret:api_key}
# gets value of env variable PATH_TO_SECRET_FILE, then loads the contents of the file it points to
password: ${loadFileFromEnv:PATH_TO_SECRET_FILE}
That approach does seem even better, it makes it very clear what you're loading and you don't have to implement more than needed now.
I need this to use Glance with sops-nix — can't wait!
We agree that this ${secret:name} variable is not Docker-specific, right?
@anotherhadi It simply reads the contents of the file at /run/secrets/<whatever name you give it>, it's not limited to Docker in any way. You can have a look at the current implementation here.