Docker-transmission-openvpn: Support for docker secrets

[NoMoreNicksLeft]

In the latest version of docker, it has a facility for using "secrets", such that they don't have to be entered onto the command line or left in unencrypted files like docker-compose.yml.

Can this image be modified to look for the openvpn password there?

I've found several solutions for this, but they all require doing up my own Dockerfile and messing with the entrypoint, something I don't feel comfortable doing.

[mustanggb]

It would be nice, I'd also like to use it for TRANSMISSION_RPC_PASSWORD, however I think the problem is jwilder/dockerize doesn't support secret injection into templates.

So the obvious options I can think of are to either fix this upsteam (i.e. in jwilder/dockerize), or to move to a different templating engine that does support this, I had a quick poke around and found markriggins/dockerfy, not sure if it's suitable, and it hasn't been updated for a while, but maybe that's fine, or maybe there are other alternatives.

[Carbohydron]

I'd love for this issue to be revisited. If I can move my credentials to a secrets file, then I could more easily share my docker-compose with others!

[Carbohydron]

Bump! I'm hoping that eventually this feature will be implemented.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Carbohydron]

Bump! I'm still hoping for this feature

[pkishino]

feel free to create a PR, I had a quick look and there is a PR on jwilder/dockerize to support this but that project doesnt update much ...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Feel free to re-open this issue if you think it deserves another look.

[haugene]

Allright. So stale bot closed this one, but I had it in the back of my mind and wanted to have a look at it. It seems to me like this feature would make most sense in a Docker swarm setup, is that what you're running?

It does also work with docker-compose and I've tested the change I just committed ☝️ by using this compose file.
NOTE: I built the image locally and the feature is not yet a part of the official :dev tag image.

version: '3.8'
services:
  transmission-openvpn:
    image: haugene/transmission-openvpn:dev
    environment:
        - OPENVPN_PROVIDER=PIA
        - OPENVPN_CONFIG=Israel
        - LOCAL_NETWORK=192.168.0.0/16
    cap_add:
        - NET_ADMIN
    ports:
        - '9091:9091'
    secrets:
        - transmission-user-pass

secrets:
    transmission-user-pass:
        file: ./user-pass.txt

Would this be a good solution? I want your comments here. Because the user-pass.txt file that I'm referring to here is an unencrypted file. And to me there is no difference in this and just mounting the username and password file to /config/openvpn-credentials.txt which has been supported for a long time. Now you might not have known that, and that's OK. Just want to hear your thoughts. The added benefit of this approach is of course that we actually will support secrets in swarm mode.
The contents of the file is just two lines:

password

which is how OpenVPN reads credentials from a file.

As you can see in my commit I'm just copying the secret into the OpenVPN credentials file. The reason for this is that we've modified all the .ovpn files of the providers to point to this file. So changing the location and reading directly from secrets would be a larger change. Another question is if it matters, it will be mounted unencrypted into the container anyways.

There is also a new feature on the dev branch that lets you supply a URL directly to the .ovpn file and then the container will download it and modify it as needed. That script could directly reference the secret and we wouldn't have to copy it. But for the built in providers we would have to make another script to fix it.

[Carbohydron]

Ah, that works! Thank you very much!

I indeed was _not_ aware this was already possible. I'm running it in docker-compose and like to share my docker-compose file. I used to have to strip out my auth before sharing but now I don't! Much appreciated

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ilike2burnthing]

bump

[haugene]

Aha. This went stale again. You want the commit :point_up: merged @ilike2burnthing ?

[ilike2burnthing]

Not something I'd personally use. Sorry, should have explained my bump - I knew you were away at the time and didn't want the post to be lost to the stale bot if you hadn't seen CH's response.