3-part port binding for docker run or docker-compose is not respected, so services can be exposed on network

[rfay]

Description

(bouncd back from lima-vm/lima#655)

macOS 12.2 arm64, colima 0.3.2, limactl version 0.8.2, docker back-end

docker/docker-compose support a 3-part port-binding technique where the interface to bind to can be chosen explicitly. For example:

docker run -p 127.0.0.1:8080:80 --name nginx -d nginx

Given that example, you should be able to curl localhost:8080 on the system where you ran it, but you should not be able to connect from another interface. For example, if 10.211.55.2 is another interface, curl 10.211.55.2:8080 should fail.

This has very serious security implications for applications that are not supposed to bind to all interfaces, see

• colima integration: Ports are exposed to the host for world-wide exposure ddev/ddev#3560

When you bind to all interfaces (the default, 0.0.0.0) it typically means that any user on the local network can access any service running under lima.

To demonstrate this,

1. run the example nginx container: docker run -p 127.0.0.1:8080:80 --name nginx -d nginx
2. Connect from localhost, curl localhost:8080 - you'll see the default nginx output
3. Connect to another interface on your machine, curl 10.211.55.2:8080 for example, and it will also show the default nginx output. It should not.

You can repeat the same with any version of docker and you won't see this exposed behavior.

[rfay]

Explanation there by @AkihiroSuda

Lima does not listen on 0.0.0.0 by default, but Colima does:

colima/environment/vm/lima/yaml.go

Lines 54 to 63 in ac876a5

	// handle port forwarding to allow listening on 0.0.0.0
	l.PortForwards = append(l.PortForwards,
	PortForward{
	GuestIP: net.ParseIP("127.0.0.1"),
	GuestPortRange: [2]int{1, 65535},
	HostIP: conf.PortInterface,
	HostPortRange: [2]int{1, 65535},
	Proto: TCP,
	},
	)

[abiosoft]

Colima used to bind to 127.0.0.1 by default but was changed to 0.0.0.0 due to a user request and there were no objections at the time. I reluctantly decided to go with that after noticing the default behaviour for Docker Desktop was to bind to 0.0.0.0.

You can still workaround that by using the --port-interface flag.

colima start --port-interface 127.0.0.1

As at now, there is no way to distinguish between a port forward of 127.0.0.1 and 0.0.0.0 from Lima VM to the host, which prevents taking full advantage of the 3-part port-binding of docker/docker-compose.

[abiosoft]

I would do some more investigations to see how this can be properly supported.

[rfay]

Thanks, yes, the current default is pretty problematic, major security issues. For example, on ddev it would mean that anybody on the local network could access and alter the database of a project. It also is overriding the explicit configuration given to the container.

[abiosoft]

This has been fixed upstream in Lima and tested successfully.
It will be part of the next release.

[rfay]

Thanks so much. It wasn't my understanding that lima-vm/lima#660 was actually fixing this problem...

[abiosoft]

@rfay can you kindly try with the latest development version and see if this is fixed? brew install --head colima.

[rfay]

I confirm that with HEAD colima both issues are solved, thanks so much!

• Bound ports with 3-part binding and using localhost are no longer accessible on other interfaces.(here and [Colima] 3-part port binding for docker run or docker-compose is not respected, so services can be exposed on network lima-vm/lima#655).
• Both host.docker.internal and host.lima.internal are defined and usable inside a plain-vanilla debian container, (host.lima.internal should be defined *inside* running containers lima-vm/lima#491 and various other issues.

[abiosoft]

Thanks for confirming, will create a release soon.