[FEATURE] Read Password/Token from /run/secrets

[IljaN]

Is your feature request related to a problem? Please describe.
Podman and Docker are able to mount a secrets file in to /run/secret i.e. /run/secrets/gf_admin_pass. Grafana is able to refer to the secret via an env var: GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/admin_password. As far as I can tell it is not possible to pass the same secret path to gdg which in my setup is installed inside the Grafana container.

Describe the solution you'd like
The GDG_CONTEXTS__ALL__PASSWORD env var should get the capability to refer to a password-file. Maybe by adding a "_FILE" suffix akin to Grafana: GDG_CONTEXTS__ALL__PASSWORD_FILE=/run/secrets/gf_admin_pass

Describe alternatives you've considered
Writing a script which reads the password file and writes it in to importer.yml. This makes the setup more convoluted and might require a custom Grafana Image.

[IljaN]

Found a workaround with a wrapper script:

#!/bin/bash
GDG_CONTEXTS__ALL__PASSWORD=$(< "$GF_SECURITY_ADMIN_PASSWORD__FILE") exec /usr/share/grafana/bin/gdg-bin "$@"

[safaci2000]

I haven't had much experience with this feature in yet. Though, if you can mount a file as a secret, can't you simply mount the importer.yml as a secret and reference it? I'm trying to understand the advantages this feature gives you.

All the docs I found basically use the secret to mount the sensitive config, why not simply do this?

version: "3.8"
services:
  app:
    image: ghcr.io/esnet/gdg:0.7.2
    command: ["-c", "/run/secrets/config.yml", "tools", "contexts", "show"]
    secrets:
      - config.yml

secrets:
  config.yml:
    file: ./importer.yml

I could see more of a use case where the entire secure folder is mounted via /var/run/secure. I think the intent is to put any sensitive data in /run/secrets in which case I think the pattern you have works fine. Having a file alternative for each potential cred is too messy IMO.

I think if we were to add support for this, it would be to look for a grafana_context_auth.json that would override the yaml config you'd store in the importer.yml and maybe add a setting like secret_location

[IljaN]

I can only speak about podman as I never really used the secrets functionality within docker but it appears to be similar. Also please take everything with a grain of salt as I am no container pro either. ;)

The use-case is as follows: You can create a "global" named secret within the container runtime using the CLI unrelated to any specific docker,file, container etc:

$ printf "MySecretPassw0rd" | podman secret create gf_admin_pass -
$ podman secret ls
ID                         NAME           DRIVER      CREATED      UPDATED
0d1e33f8a80c0b923a31cd01b  gf_admin_pass  file        2 weeks ago  2 weeks ago

The secret can then be referenced by the name "gf_admin" in any container definition/dockerfile/compose/whatever on the system and gets injected by the container runtime automatically as file "gf_admin_pass".

[Container]
Image=docker.io/grafana/grafana-oss:11.6.1
PublishPort=3000:3000
EnvironmentFile=./.env
Secret=gf_admin_pass 

The advantage is to my understanding that the secret does not need to appear in any .env or other config files where someone could either forget to change it or commit it accidentally. The secret must be created explicitly during the setup. The default behavior of the podman secret driver is to mount every secret as a separate file. It happens "magically" and I don't need to configure any volumes/mounts manually.

The advantage of supporting the secret file in GDG would be that the container definition can be kept DRY and both Grafana and GDG can refer to the same secret without the need to template importer.yml or do other gymnastics. My importer.yml does not contain any secrets anyways and things like Grafana URL are injected via env-var.

Hope that makes sense.

[safaci2000]

I ended up writing an example documentation on how to use secrets since you brought it up. https://github.com/esnet/gdg/blob/main/website/content/docs/cookbook/docker_example.md

It's not live yet, but will go out with the next release. The way I configured it at least, you still end up a file on the system.

I believe that you don't have anything polluting to her env which is one advantage, it also gets mounted to a special path.

Would the suggested fix for #421 support your use case? I don't think you can have a secret as a folder but I think you can still mount them all in the same location

[safaci2000]

Created ticket for related work. #421 feel free to expand on it

[csg33k]

@IljaN I released v0.8.0 with docs for how to do what you were asking for: https://software.es.net/gdg/docs/cookbook/docker-compose-example/. Let me know if this work for you.

[IljaN]

Wow! Thanks a whole lot @safaci2000 @csg33k 💪 . Sorry for the late feedback, was a out of the loop for a bit. I will let you know. But looks good so far from what I saw.

Thanks again! ❤️

[safaci2000]

@IljaN I have not used this pattern much in docker compose I provided an example that works. It does make sense to move the secrets out of the main config. Just be careful with any helper tools that update the config. They might leak the data. On a future version I'll likely remove all creds from importer.yml and secrets/ volume will just end up with any sensitive info.

I actually forgot about the S3 stuff. I'll open a ticket around that as well