Support Docker's host.docker.internal:host-gateway special host

[rugk]

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

/kind feature

Description

Docker has a feature since v20.10.0+ for Linux (at least according to Stackoverflow) here you can add a special host --add-host=host.docker.internal:host-gateway, which refers to the host system, so you can access their ports from a container.

Now podman does not seem to support that this way, at least…

Steps to reproduce the issue:

$ podman run --rm --name test --add-host host.docker.internal:host-gateway busybox sh -c 'set -x&&cat /etc/hosts&&ping host.docker.internal'
Error: invalid IP address in add-host: "host-gateway"

Describe the results you received:
Well… it says invalid IP address, which makes it incompatible with Docker, I guess, at least as a drop-in solution. 😅

Describe the results you expected:
Offer Docker compatibility here, i.e. it should also resolve to the hosts IP address?

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

Accidentally though, I've noticed you can use another domain and just do this host.containers.internal…

$ podman run --rm --name test busybox sh -c 'set -x&&cat /etc/hosts&&ping host.containers.internal'
Resolved "busybox" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/busybox:latest...
Getting image source signatures
Copying blob b71f96345d44 done  
Copying config 69593048aa done  
Writing manifest to image destination
Storing signatures
+ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

# used by slirp4netns
10.0.2.2	954ad610242e test
10.0.2.2 host.containers.internal
+ ping host.containers.internal
PING host.containers.internal (10.0.2.2): 56 data bytes
ping: permission denied (are you root?)

However it has some differences…:

• in contrast to docker it seems to be always written in there
• I see no way to customize the hostname with a command like --add-hosts, i.e. in Docker you could do --add-host=my-own-domain-name:host-gateway. This is not possible in podman via this way…
  At least the obvious "polyfill" --add-host host.docker.internal:host.containers.internal does not work…

Also, it seems podman always copies or mounts /etc/hosts from the host into the container (i.e. the part before # used by slirp4netns), I wonder whether they is really done deliberately…

BTW, yes my example uses ping, nslookup always failed to solve the IP for whatever reason…

Output of podman version:

$ podman version
Version:      3.2.0
API Version:  3.2.0
Go Version:   go1.16.3
Built:        Wed Jun  9 16:24:16 2021
OS/Arch:      linux/amd64

Also reproduced with:

$ podman version  
Version:      3.2.2
API Version:  3.2.2
Go Version:   go1.16.4
Built:        Sat Jun 26 01:49:19 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

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

Physical
Tested with Fedora CoreOS 34.20210611.3.0
And Fedora Workstation 34

[rugk]

Oh but host.containers.internal is not routable/the network is not reachable by default, unfortunately, so it is actually also functionally different to host.docker.internal / host-gateway of Docker.

# wget http://host.containers.internal
Connecting to host.containers.internal (10.0.2.2:80)
wget: can't connect to remote host (10.0.2.2): Network unreachable

[rugk]

Ah just see this feature is only there since podman v3.2.0: #5651 and #9972 /cc @kermorgant

However, … I still think it does not work as what I'd expect from Docker.

[mheon]

From Podman 3.2.x and up, we're doing this automatically. A side effect of this is that we don't support the Docker CLI syntax. We could change to be more compatible by requiring their special invocation of --add-host to add the record, but I don't really see any reason why you wouldn't want this in /etc/hosts so the easiest way forward is to continue doing what we're doing and ignore/remove any host.docker.internal:host-gateway entries from add-hosts.

[rugk]

Okay, good to know. So, however, the routing does not work as I commented in #10878 (comment) – or should I open a new issue for that?

Say a HTTP server is running on port 1234 on the host…
Then http://host.containers.internal:1234 from the container does not work… while http://hostname-of-server-here:1234 works, as that resolves to the external IP of the host device.

The disadvantage of using the hostname is that you then cannot use a firewall to block the ports from the outside, but all ports actually need to be accessible from the outside (in my example here port 1234). This is what I don't want.
(And no I cannot use podman networks for that, as the podman containers run in different user accounts for additional privilege separation.)

[mheon]

Root or rootless Podman? I would expect that this would work, but only as root

[rugk]

Rootless.

[mheon]

This sounds expected, then, given the limitations of the rootless network stack. The "host" in the rootless sense is not a pointer to an IP on the host, but to the internal slirp4netns IP where traffic from the host originates. Rootless does not have the privileges required to configure proper network bridges, so instead traffic is tunneled from the host into the container; a side effect of this is that communication from host to container is limited to only forwarded ports. There is an option to expose the host's localhost into the container, albeit there are security implications to doing so (applications binding to localhost on the assumption that it is not shared)

[rugk]

There is an option to expose the host's localhost into the container, albeit there are security implications to doing so (applications binding to localhost on the assumption that it is not shared)

Oh yeah --net host or yeah… this is also not good, you're correct. Hmm, … kinda bad situation for my use case…

[rugk]

Oh but doing --network slirp4netns:port_handler=slirp4netns as in #10884 would not solve this problem too, would it? (I just switched to host networking now as it was easier and solves both problems…)

[mheon]

I don't believe so, no - you still don't have a bridge between the host and container, so traffic can't be routed straight from host to container.

[Luap99]

--network slirp4netns:allow_host_loopback=true will allow access to the host loopback via 10.0.2.2.
https://github.com/containers/podman/blob/main/docs/source/markdown/podman-create.1.md#--networkmode---net

[rugk]

@Luap99 Oh thanks 10.0.2.2 should equal the new host.containers.internal I guess, so we can just use that domain name instead?

Opened PR #10892 for that…

[rhatdan]

I think this issue is fixed, reopen if I am mistaken, or open a new issue.

# ./bin/podman run alpine grep host.containers.internal /etc/hosts
10.88.0.1 host.containers.internal
$ ./bin/podman run alpine grep host.containers.internal /etc/hosts
10.0.2.2 host.containers.internal

[AlexanderYastrebov]

There is an option to expose the host's localhost into the container, albeit there are security implications to doing so (applications binding to localhost on the assumption that it is not shared)

But podman --network --host doesn't work on MacOS #15664