5 ms·

What do you mean by sanely sharing users in the container?

by saganus 10y ago

taeric 10y ago
An example is easiest. I have my machine setup to provide who I am to machines I ssh to. Now, launch a container that you want to pull data from a machine that you have ssh access to. First, you'll find that the user used to setup the container was not you. So you can't even just map in your .ssh dir. So you'll try modifying the image to work with specified user at start up. Only, again, it wasn't setup that way. You will start modifying the entire image to work, but will hit tons of assumptions on user name. (You may get lucky here. I didn't.) So then you think to just run as root so that the user in the container will have permission to your .ssh files. At first you forget to specify user name on ssh commands, since the command thinks you are root now. easy enough, at least. Only, you forgot you have proxy commands in your config and other scripts that you now have to edit because they rely on your user name. So you can fix that. Now you can finally do what would have been trivial for an app installed on your machine.
- Diederich 10y ago
  This is well stated. I have been making end-user apps for myself and for folks at work that require such identity, in one case, ~/.ssh, and in another, ~/.gnupg. My solution isn't particularly novel or clever, but it works well. The docker image of the command-line app is the same for all users, and so lacks their identity built in. The hack is to drive invocation of the docker image with a shell script that makes a temporary directory, copies in the necessary identity files from ~, and does a docker run that maps those identify files into the docker image. After the docker image exits, the bash invocation script cleans up. It's a hack, but it works surprisingly well. In my tests, it adds about 100ms of invocation latency for a python program. That is, running the docker image containing a python program that copies some files in as described is about 100ms slower than just running the same python program directly. It would be nice to have a more elegant solution to this, but it's not too bad.
  - tomjakubowski 10y ago
    disclaimer: I am not a security expert. Reader beware! If you're using ssh-agent, maybe you could bind-mount your host's $(dirname $SSH_AUTH_SOCK) into the container, and then set the SSH_AUTH_SOCK environment variable to point at it when you run the Docker container. That way you're not even sharing the private key with the container. I imagine you could do the same with gpg-agent, too.
    - Diederich 10y ago
      I didn't think about that, thanks! I didn't mention it, but for one of the apps, I also needed ~/.gitconfig, which I don't think has an agent. :(
  - taeric 10y ago
    I think this is the common solution. It definitely feels like a hack, though. I thought of the ssh-agent trick, but never thought of how to actually do it and moved on to other problems. I would love to hear thoughts on better ways to fix this. Apologies for not responding earlier, as I really want this conversation to end somewhere. I just feel ashamed that I don't know how to continue it. I do want to throw out there that this should not keep folks from trying docker. Please try it. Even better, suggest ways to advance this use case.
- saganus 10y ago
  I see. This is an interesting problem, and I would think one that a lot of people are experiencing. Seems like an area of opportunity to make docker images a lot more flexible.
  - taeric 10y ago
    Apologies for the slow response on this post. I would love to think of ways to fix this. I think most uses of docker today involve deploying applications that you do want completely sandboxed. And for those, this works rather well. Hopefully this doesn't keep you from trying it. (Indeed, you may have a nice solution to this that escaped me.)
    - angersock 10y ago
      Unless I grossly misread your problem--which I may have!--it seems like you're trying to handle authentication and accounts on the docker instance. What's wrong with using ye olde Kerberos and LDAP to accomplish this exactly?
      - taeric 10y ago
        That is certainly a path I considered. However, having to setup either of those is not exactly trivial. And not something I care to do for a user application.
- cheez 10y ago
  You're not doing things the "Docker" way. If you've got data you want to pull out, use a mounted volume and get it out that way.
  - taeric 10y ago
    This doesn't really change anything. I want to put data in and then take derived data out. All while maintaining access protections to my user on the host system.
    - cheez 10y ago
      That's what mounts let you do. I'm not sure why you don't agree.
      - taeric 10y ago
        That is what they do nominally. But for existing data, it falls flat. Hard. Again, an example is easiest. (Will also shed light on if I am actually doing something wrong. Entirely in the realm of plausible.) So, you have a file share with your data, scoped to user "cheez". You can ssh to machine "remote" and see this data. You can copy this data over to your machine, call it "local" and it will still be scoped to your user, "cheez". This is great, as you don't have to worry about someone else accidentally getting access to it. However, you decide to use "container A" to run some analysis on this data. The folks that setup "container A" did so using the username "container". You mount your data on a volume to "/my/data". You check, and the container can now see it, but user "container" does not have permission to do anything with it. You have plenty of options at this point. You can give public permissions to see the data in the directory. You can launch ssh from in the container and copy the data in. (Note that this way will have the data in the container as belonging to "container" which will make similar concerns on egress.) You can also run the container as "root" which will clearly have permission. However, recognize the concerns with this approach, as this also gives you permission to see any other file in that directory that "cheez" wouldn't normally have permission to see. You can also recreate the container such that "cheez" is the user that is created in the container. This sounds great, but redoing the entire setup of the image has a few problems. Not to mention the security implications this has, since you could also recreate the image with the user of your boss and circumvent some other security measures of your machine. Now, if your container doesn't set anything up in userspace (defined as "not root") until launch of the container, much of this concern goes away. Not all of it, I believe, but most. However, anything that you want to run "in the container" using your identity from "out of the container" seems to fall into this trap. It is subtle, but gets in the way of a lot of use cases.

What do you mean by sanely sharing users in the container?

by saganus 10y ago

What do you mean by sanely sharing users in the container?

An example is easiest. I have my machine setup to provide who I am to machines I ssh to. Now, launch a container that you want to pull data from a machine that you have ssh access to. First, you'll find that the user used to setup the container was not you. So you can't even just map in your .ssh dir. So you'll try modifying the image to work with specified user at start up. Only, again, it wasn't setup that way. You will start modifying the entire image to work, but will hit tons of assumptions on user name. (You may get lucky here. I didn't.) So then you think to just run as root so that the user in the container will have permission to your .ssh files. At first you forget to specify user name on ssh commands, since the command thinks you are root now. easy enough, at least. Only, you forgot you have proxy commands in your config and other scripts that you now have to edit because they rely on your user name. So you can fix that. Now you can finally do what would have been trivial for an app installed on your machine.

Diederich 10y ago
This is well stated. I have been making end-user apps for myself and for folks at work that require such identity, in one case, ~/.ssh, and in another, ~/.gnupg. My solution isn't particularly novel or clever, but it works well. The docker image of the command-line app is the same for all users, and so lacks their identity built in. The hack is to drive invocation of the docker image with a shell script that makes a temporary directory, copies in the necessary identity files from ~, and does a docker run that maps those identify files into the docker image. After the docker image exits, the bash invocation script cleans up. It's a hack, but it works surprisingly well. In my tests, it adds about 100ms of invocation latency for a python program. That is, running the docker image containing a python program that copies some files in as described is about 100ms slower than just running the same python program directly. It would be nice to have a more elegant solution to this, but it's not too bad.
- tomjakubowski 10y ago
  disclaimer: I am not a security expert. Reader beware! If you're using ssh-agent, maybe you could bind-mount your host's $(dirname $SSH_AUTH_SOCK) into the container, and then set the SSH_AUTH_SOCK environment variable to point at it when you run the Docker container. That way you're not even sharing the private key with the container. I imagine you could do the same with gpg-agent, too.
  - Diederich 10y ago
    I didn't think about that, thanks! I didn't mention it, but for one of the apps, I also needed ~/.gitconfig, which I don't think has an agent. :(
- taeric 10y ago
  I think this is the common solution. It definitely feels like a hack, though. I thought of the ssh-agent trick, but never thought of how to actually do it and moved on to other problems. I would love to hear thoughts on better ways to fix this. Apologies for not responding earlier, as I really want this conversation to end somewhere. I just feel ashamed that I don't know how to continue it. I do want to throw out there that this should not keep folks from trying docker. Please try it. Even better, suggest ways to advance this use case.
saganus 10y ago
I see. This is an interesting problem, and I would think one that a lot of people are experiencing. Seems like an area of opportunity to make docker images a lot more flexible.
- taeric 10y ago
  Apologies for the slow response on this post. I would love to think of ways to fix this. I think most uses of docker today involve deploying applications that you do want completely sandboxed. And for those, this works rather well. Hopefully this doesn't keep you from trying it. (Indeed, you may have a nice solution to this that escaped me.)
  - angersock 10y ago
    Unless I grossly misread your problem--which I may have!--it seems like you're trying to handle authentication and accounts on the docker instance. What's wrong with using ye olde Kerberos and LDAP to accomplish this exactly?
    - taeric 10y ago
      That is certainly a path I considered. However, having to setup either of those is not exactly trivial. And not something I care to do for a user application.
cheez 10y ago
You're not doing things the "Docker" way. If you've got data you want to pull out, use a mounted volume and get it out that way.
- taeric 10y ago
  This doesn't really change anything. I want to put data in and then take derived data out. All while maintaining access protections to my user on the host system.
  - cheez 10y ago
    That's what mounts let you do. I'm not sure why you don't agree.
    - taeric 10y ago
      That is what they do nominally. But for existing data, it falls flat. Hard. Again, an example is easiest. (Will also shed light on if I am actually doing something wrong. Entirely in the realm of plausible.) So, you have a file share with your data, scoped to user "cheez". You can ssh to machine "remote" and see this data. You can copy this data over to your machine, call it "local" and it will still be scoped to your user, "cheez". This is great, as you don't have to worry about someone else accidentally getting access to it. However, you decide to use "container A" to run some analysis on this data. The folks that setup "container A" did so using the username "container". You mount your data on a volume to "/my/data". You check, and the container can now see it, but user "container" does not have permission to do anything with it. You have plenty of options at this point. You can give public permissions to see the data in the directory. You can launch ssh from in the container and copy the data in. (Note that this way will have the data in the container as belonging to "container" which will make similar concerns on egress.) You can also run the container as "root" which will clearly have permission. However, recognize the concerns with this approach, as this also gives you permission to see any other file in that directory that "cheez" wouldn't normally have permission to see. You can also recreate the container such that "cheez" is the user that is created in the container. This sounds great, but redoing the entire setup of the image has a few problems. Not to mention the security implications this has, since you could also recreate the image with the user of your boss and circumvent some other security measures of your machine. Now, if your container doesn't set anything up in userspace (defined as "not root") until launch of the container, much of this concern goes away. Not all of it, I believe, but most. However, anything that you want to run "in the container" using your identity from "out of the container" seems to fall into this trap. It is subtle, but gets in the way of a lot of use cases.