Feature request: simplify exposing the machine socket on OS X

[orpiske]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature

Description
I'd like to suggest adding a way to expose the remote machine socket (/run/user/1000/podman/podman.sock) more easily.

Steps to reproduce the issue:

1. On a OS X machine, with podman running

2. In order to expose the socket on the machine, you have to run a command similar to this:

sshPort=$(ps -ef | grep -i gvproxy | grep -v grep | sed 's/.*ssh-port //')

ssh -i ~/.ssh/podman-machine-default -p $sshPort -L'/tmp/podman.sock:/run/user/1000/podman/podman.sock' -N core@localhost

Describe the results you received:

The local socket is created, but it requires extra steps to expose the socket.

Describe the results you expected:

Instead of running the two commands above, I would like to suggest adding a new command to podman. Something similar to: podman machine expose. The command would create local socket using a ssh tunnel just like the commands above.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Client:
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.17
Built:        Mon Aug 30 21:15:26 2021
OS/Arch:      darwin/amd64

Server:
Version:      3.3.0
API Version:  3.3.0
Go Version:   go1.16.6
Built:        Fri Aug 20 21:36:14 2021
OS/Arch:      linux/amd64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes/No

Additional environment details (AWS, VirtualBox, physical, etc.):

[afbjorklund]

On Linux, you can just use one of the two "connections" set up by podman machine:

$ podman system connection ls
Name                         Identity                                  URI
podman-machine-default-root  /home/anders/.ssh/podman-machine-default  ssh://root@localhost:46355/run/podman/podman.sock
podman-machine-default*      /home/anders/.ssh/podman-machine-default  ssh://core@localhost:46355/run/user/1000/podman/podman.sock
$ podman --remote --connection podman-machine-default info | grep -i rootless
    rootless: true
$ podman --remote --connection podman-machine-default-root info | grep -i rootless
    rootless: false

You don't need a local unix socket, unless you want to use the Docker compatibility ?

Like in: #11397 (comment)

[orpiske]

On Linux, you can just use one of the two "connections" set up by podman machine:

$ podman system connection ls
Name                         Identity                                  URI
podman-machine-default-root  /home/anders/.ssh/podman-machine-default  ssh://root@localhost:46355/run/podman/podman.sock
podman-machine-default*      /home/anders/.ssh/podman-machine-default  ssh://core@localhost:46355/run/user/1000/podman/podman.sock

You don't need a local unix socket, unless you want to use the Docker compatibility ?

Thanks!

Yes, we use docker compatibility in order to run container-based tests using TestContainers. So, I am just trying to find an easy way to have it find the socket.

Basically, after I ran those 2 commands above to create the local socket, then I expose it using:

export DOCKER_HOST=unix:///tmp/podman.sock

This way, the library I mentioned finds and socket and can manage the containers using the docker API.

What I was hoping to do, instead of running those commands, is doing something like this:

export DOCKER_HOST=$(podman machine expose)

[orpiske]

I missed the command you had linked.

Like in: #11397 (comment)

That's exactly it! A lot of these Docker client libraries in Java use the Docker API (through the socket or via TCP) in order to manage the containers.

[afbjorklund]

Hopefully, even Docker clients will soon be able to use ssh: host URLs.

Then you could just do export DOCKER_HOST=$CONTAINER_HOST

(assuming some workaround for the $CONTAINER_SSHKEY, like ssh-add)

But meanwhile, some legacy/compatibility workaround like this might be needed...

[afbjorklund]

https://docs.docker.com/engine/security/protect-access/#use-ssh-to-protect-the-docker-daemon-socket

export DOCKER_HOST=ssh://[email protected]

I guess someone needs to tell the Java people ?

https://docs.docker.com/engine/release-notes/18.09/#new-features

[orpiske]

https://docs.docker.com/engine/security/protect-access/#use-ssh-to-protect-the-docker-daemon-socket

export DOCKER_HOST=ssh://[email protected]

I guess someone needs to tell the Java people ?

That's a fair point and I think that the community will eventually add support for this as it becomes a widespread requirement.

On the other hand, I think there's still a lot of older versions of those libraries that used to run just fine with Docker (via socket / tcp) which would be good (IMHO, of course) to support with minimal effort.

[mheon]

This looks like a dupe of #11397 - this is more succinctly stated, but that one has more discussion... I think we probably ought to close that one and proceed here, given that this is really a feature request as you identify.

[afbjorklund]

Just need a clarification that it is about exposing the Docker (compatibility) socket as a local file due to ignorant tools,
or perhaps come up with some motivation why the Podman socket is better used with an explicit tunnel for the socket ?

Otherwise there is no real reason why you couldn't do the same for podman.sock, just a small question of "why would you want to". For the docker.sock, there was the Java tools not understanding SSH and the Docker tools not allowing different socket paths.

[afbjorklund]

We used to do this as a simple one-liner in the shell for podman-machine, but maybe it's enough to warrant a special command ?

podman-machine ssh box -L 8080:localhost:8080 -N &
curl http://localhost:8080

Something like: (which doesn't work at the moment, due to the new command not understanding the -- args divider properly)

podman machine ssh -L '/tmp/docker.sock:/run/user/1000/podman/podman.sock' -N &
export DOCKER_HOST=unix:///tmp/docker.sock

[orpiske]

Thanks for taking the time to evaluate my suggestion!

I am not entirely sure if the question was directed to me, but I'll comment sharing my point of view as user.

Just need a clarification that it is about exposing the Docker (compatibility) socket as a local file due to ignorant tools,
or perhaps come up with some motivation why the Podman socket is better used with an explicit tunnel for the socket ?

Otherwise there is no real reason why you couldn't do the same for podman.sock, just a small question of "why would you want to". For the docker.sock, there was the Java tools not understanding SSH and the Docker tools not allowing different socket paths.

I see it as exposing the docker compatibility socket as a local file so that legacy tools can work with/manage containers with Podman.

And from this same perspective, I would like to avoid having to worry about podman details (i.e.: the path of the socket within the machine /run/user/1000/podman/podman.sock, the name of the socket file, as well as the user ID it runs with).

So, as a user, it offers a better user experience by condensing these steps and hiding away the specifics of the podman runtime.

We used to do this as a simple one-liner in the shell for podman-machine, but maybe it's enough to warrant a special command ?

I think the one-liner is very close to what would be ideal. If it could be condensed to podman-machine ssh expose socket &, it would be great (no need to worry with the host or guest, ports, the hostname, etc).

[afbjorklund]

And from this same perspective, I would like to avoid having to worry about podman details (i.e.: the path of the socket within the machine /run/user/1000/podman/podman.sock, the name of the socket file, as well as the user ID it runs with).

Agree, it would be nice if this interacted seamlessly with "connections" and worked more like your initial suggestion, returning the path to the temporary socket. Also means the user does not have to worry about the local socket, it would be more like mktemp

[maxandersen]

related #11422

[n1hility]

FYI, proposal for this: #11643

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@n1hility Any update on this?

[rhatdan]

Looks like containers/gvisor-tap-vsock#58 merged, what's next?

[n1hility]

@rhatdan we don't have much to go. We just need a simple podman machine wrapper to call this, to get it done. I had a few other critical things I needed to get done so was just now coming back to it. @baude wants to take a quick look at the podman machine portion. He mentioned we might want multi-socket forwarding in gvproxy. I can whip that up quick.

[baude]

I'm working on it ... as @n1hility said the current implementation only allows the mapping of one socket. I'm not sure if that is sufficient. the next problem is getting it straight in our heads on how this in fact works (logistically). The implementation should not take very long at all.

[n1hility]

@rhatdan @baude sorry for the delay, something else came up, but PR is done for multi-socket:

containers/gvisor-tap-vsock#66

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@baude @n1hility What needs to be done to get this exposed now.
Do we still need a
podman connection docker-env or something to show the DOCKER_HOST environment variables?

[n1hility]

@rhatdan IMO we should support both. We should listen on a generated sock in data, and also optionally link the docker API locations. This would support both the case of a podman exclusive system and one running both podman and docker desktop in the process of transition.

I am currently working on a win support PR, but next thing to look at was win proxy support via a mini gvproxy. As soon as I get to that I will sync with @baude on the remaining mac pieces.

[ghost]

My PR for containers/gvisor-tap-vsock/issues/41 should solve this issue, I think.

[n1hility]

My PR for containers/gvisor-tap-vsock/issues/41 should solve this issue, I think.

@protosam this issue is a little different. In this case we need to consume gvproxy’s recent support (see above comments) of Unix to Unix forwarding over ssh. In this particular use case we want to avoid podman acting as a daemon or listening over TCP.

[ghost]

In the case of the podman machine and the podman client itself, it wont be listening over tcp even though the inside of the vm might be. You can have rootless podman on a different port than the rootful podman daemons. The unix-to-tcp proxy achieves the desired results (unix-to-unix coming soon ™️ as well, without ssh).

Edit:
After thinking on your comment @n1hility, it has occurred to me that if a container is compromised, processes inside can talk to the TCP socket.

Going to update my PR to add unix-to-unix (over SSH) in the forwarder service.

[n1hility]

Hi @protosam the gvproxy pieces were implemented here: containers/gvisor-tap-vsock#58 and here containers/gvisor-tap-vsock#66

Although this was a static approach since it’s tied to the life the of VM. Dynamic registration might be be interesting for other applications though

The remaining bits for this use case on mac are on the podman side: consuming it, creating the proper links and display guidance in an info message.

[ghost]

The unix-to-unix over ssh forwarding has been added in my PR.

@n1hility I feel like gvproxy could be a better tool that services more than just podman; but as long it's stack is statically configured and it has flags for proxying things out of band of the VirtualNetwork's services, it will remain service-locked to podman. The more flexible the tool is, the more people that will likely contribute to it for their needs.

[n1hility]

The unix-to-unix over ssh forwarding has been added in my PR.

@n1hility I feel like gvproxy could be a better tool that services more than just podman; but as long it's stack is statically configured and it has flags for proxying things out of band of the VirtualNetwork's services, it will remain service-locked to podman. The more flexible the tool is, the more people that will likely contribute to it for their needs.

@protosam Happy New Year! Sorry for the delay in replying to your comment, and the brief replies earlier. I was away during the holidays with a busy schedule and traveling back was a bit of chaos. Thank you for contributing, I added a note to your PR. While the existing ssh forwarding capability was introduced for the podman machine use case, it is not tied to podman, it's just a generic unix to unix over ssh forwarding service that any gvproxy user could use, save from vendored API usage. An early iteratation had an API presence, but after discussing with @guillaumerose it was decided to avoid API exposure and additional dependencies for the time being since there are downstream consumers that do not need this functionality. I think he would be interested to hear about any additional non-podman use cases you have in mind though. Although we should probably take this discussion branch to the gvisor issue, since this one is about the podman functionality.

[afbjorklund]

This was implemented in lima (0.7.3), to make it easier to access the unix sockets.

INFO[0030] READY. Run `limactl shell podman` to open the shell. 
INFO[0030] To run `podman` on the host (assumes podman-remote is installed): 
INFO[0030] $ export CONTAINER_HOST=unix:///home/anders/.lima/podman/sock/podman.sock 
INFO[0030] $ podman --remote ...                        

Just uses the regular ssh forwarding (of ports and sockets) as provided by limactl.

[MarcoR83]

I saw the windoze implementation was merged, what about macos developers? :)

[rhatdan]

Yes MACOS support is also coming in podman 4.0. Should be available end of next week.