[Feature Request] Specify WATCHTOWER_HTTP_API_TOKEN as docker secret

[lonix1]

Is your feature request related to a problem? Please describe.

When using the "HTTP API mode", the WATCHTOWER_HTTP_API_TOKEN is included in the compose file. That is a security risk:

• it is committed to source control
• it is an environment variable, so is leaked in logs

Describe the solution you'd like

Please allow us to specify the token as a docker secret. It's quite simple:

secrets:
  access_token:
    file: access_token

services:
  watchtower:
    secrets:
      - access_token
    environment:
      - WATCHTOWER_HTTP_API_TOKEN_FILE=/run/secrets/access_token
    # ...

Docker mounts the secret at /run/secrets/access_token; that container file contains the content of the access_token host file.

It is customary to add a new environment variable WATCHTOWER_HTTP_API_TOKEN_FILE, which contains the path of the secret file. The app should then read the secret from that file into memory (but never into an environment variable).

From a development perspective, the only change is to read the secret from a file instead of an env var. Everything else is handled by docker automatically.

Describe alternatives you've considered

Accepting poor security. ;)

Additional context

Thank you!

[github-actions]

Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏

[lonix1]

I see this is tagged as "Priority: Low" but I respectfully disagree. It is an awfully large security risk.

I'm not a go dev, so regrettably I can't provide a PR... sorry! I hope someone with the requisite skills can look into this.

Thanks for a really great project!

[piksel]

it is an environment variable, so is leaked in logs

That doesn't sound right. Environment variables is the de facto standard way to pass secrets.

it is committed to source control

Only if you explicitly add it. Use an .env-file to avoid checking in secrets/environment-specific configuration.

That being said, it's an easy thing to add.

[lonix1]

Environment variables is the de facto standard way to pass secrets.

Agreed 100% - it's the de facto way. Almost everyone does that.

...but it's wrong. There are a bazillion posts on StackOverflow / StackExchange that discuss that. It's why docker secrets were introduced, to avoid those issues. I used to put everything in env vars, and I was taught an expensive lesson when I ran into security problems. 😆 😆 😆

Use an .env-file to avoid checking in secrets

True. Though it solves one problem but the other remains (it is an environment variable).

That being said, it's an easy thing to add.

That would be a MAJOR boost in security. I noticed that there is already some mention of secrets in other issues, so maybe the groundwork is already there? (I wish I could contribute a PR but I'm not a go dev.)

[lonix1]

I suppose on second thought: "to each his own".

Every environment will have a different "threat model"... so people should use the approach that makes sense to them.

But to have this as a secret will help those of us who use docker secrets.

Thanks again for considering it.

[mgcrea]

Just adding that you can use env_file: .env in your docker-compose and add this file to gitignore and there is no security issues this way if you want to track the yaml changes.