从Docker容器中以不同用户身份运行命令/脚本

Question

First off, I know this may not be the most "containerized" solution to a problem. At this point though, I am wondering if I will have to scrap what I have so far or if I can make this work.

I need to move files between servers and back them up. I currently have a script which does that. The user I run this script as has keys to all the servers and thus rsync'ing from server to server is no issue for this script.

I am now creating a webservice that users can ping to move their files securely and with a backup. This prevents them having to contact me to run the script, and will allow for integration with some workflow software later on.

However, my docker container which catches the http request to the webservice will not have keys to everywhere and thus cannot run the script successfully. I am looking for a solution that will allow me to run this script while also having a webservice that users can make requests to. My original hope was for the route to basically pass on args and run the script.

I don't know the feasability of the following ideas, but they are the two thoughts I have had so far.

• Run the docker container as my user which has keys everywhere
• Give the docker keys to everywhere on startup

Would anyone have any suggestions on how to do the above or a possible solution to the problem?

Feel free to ask more questions as I know it is a weird issue. Thanks in advance for any help!

Answer 1

We can't get around the fact that something will need the keys if we're going to manually run the transfer over SSH. Similar to "give the docker keys to everywhere on startup", we could bind-mount the keys into the container as a volume:

$ docker run -d -v /host/path/to/keys:/container/path/to/keys:ro image command ...

This gives the container read-only access to the keys on the host. It also lets us update the keys on the host when needed without needing to restart the container.

We could get fancy with this by storing keys in a dedicated secrets storage service, and the container can fetch the keys when needed, but for this simple use case, I don't see the need to build more complexity than necessary.