Understanding pastas -i option and implications for network isolation

[har7an]

After upgrading to Fedora Silverblue 40, I am currently using podman 5.0.2 and had to notice that the change to pasta as default network driver/mode unfortunately breaks my workflows. In particular, I often find myself working on the road, without any networking whatsoever. With slirp4netns this worked fine, with pasta this breaks by default as has apparently been discussed at length.

I saw the following comment which describes a way around this problem. This is only a partial solution though, as pasta still needs the -i argument to know which host interface to derive addresses and routes from. Given this and the Podman 5.0 release announcement, my containers.conf now looks like this:

[network]
pasta_options = [
    # Use IPv4 networking
    "-4", "-n", "24", "-a", "10.0.2.100", "-g", "10.0.2.2", "--dns-forward", "10.0.2.3",
    # Configure network interfaces
    "-I", "tap0", "-i", "lo"
]

The interesting bit here is the -i option. First I tried filling in my network interface, but of course my interfaces are named differently across machines and, for example on my laptop, I usually have different interfaces connected depending on where I am. So I decided to just try out whether lo would work (as that's universally available) and apparently it does. With this setup I can ping from inside the container and reach e.g. websites with curl (so it also resolves DNS), provided any of my interfaces has a proper route set up.

Is this intended behavior? Can I safely do that, or does that somehow expose other things and services also running on localhost to my container? What exactly does pasta -i do in this case and why does the interface matter?

Thanks in advance!

[sbrivio-rh]

In particular, I often find myself working on the road, without any networking whatsoever. With slirp4netns this worked fine,
with pasta this breaks by default as has apparently been discussed at length.

As strange as it might sound, this is the first time I hear about "no networking" as use case. Probably most Podman users would use -net none in that case?

Or you need to show the container a pretense of networking setup, while your host is not actually connected? If that's the case, we should consider it as a possible use case, I guess.

I saw the following comment which describes a way around this problem. This is only a partial solution though, as pasta still needs the -i argument to know which host interface to derive addresses and routes from.

Why? You're passing addresses and routes manually with -a and -g. Do you get some error otherwise?

Given this and the Podman 5.0 release announcement, my containers.conf now looks like this:

[network]
pasta_options = [
    # Use IPv4 networking
    "-4", "-n", "24", "-a", "10.0.2.100", "-g", "10.0.2.2", "--dns-forward", "10.0.2.3",
    # Configure network interfaces
    "-I", "tap0", "-i", "lo"
]

The interesting bit here is the -i option. First I tried filling in my network interface, but of course my interfaces are named differently across machines and, for example on my laptop, I usually have different interfaces connected depending on where I am. So I decided to just try out whether lo would work (as that's universally available) and apparently it does. With this setup I can ping from inside the container and reach e.g. websites with curl (so it also resolves DNS), provided any of my interfaces has a proper route set up.

Is this intended behavior? Can I safely do that, or does that somehow expose other things and services also running on localhost to my container? What exactly does pasta -i do in this case and why does the interface matter?

I would expect pasta -i to do pretty much nothing in this case, as you're supplying all the information with other parameters. On top of that, it should just source the MAC address from the loopback interface (all zeroes). Certainly it doesn't expose additional services running on the host.

[har7an]

Probably most Podman users would use -net none in that case?

This doesn't really work in my case. I'll explain in greater detail below.

Why? You're passing addresses and routes manually with -a and -g. Do you get some error otherwise?

In fact I do. Without an active network connection, this is what I get:

$ podman run --rm -it hello-world
Error: pasta failed with exit code 1:
External interface not usable

$ podman run --rm -it --network pasta:-4,-n,24,-a,10.0.2.100,-g,10.0.2.2,--dns-forward,10.0.2.3,-I,tap0 hello-world
Error: pasta failed with exit code 1:
External interface not usable

$ podman run --rm -it --network pasta:-4,-n,24,-a,10.0.2.100,-g,10.0.2.2,--dns-forward,10.0.2.3,-I,tap0,-i,lo hello-world
!... Hello Podman World ...!

.....

I would expect pasta -i to do pretty much nothing in this case, as you're supplying all the information with other parameters. On top of that, it should just source the MAC address from the loopback interface (all zeroes).

This doesn't appear to be the whole truth, though:

$ podman run --rm -it --network pasta:-4,-n,24,-a,10.0.2.100,-g,10.0.2.2,--dns-forward,10.0.2.3,-I,tap0,-M,00:00:00:00:00:00 hello-world
Error: pasta failed with exit code 1:
External interface not usable

Certainly it doesn't expose additional services running on the host.

Glad to hear that, thanks a lot!

It might be slightly more convenient for users in some cases, but I'm not fond of adding more and more possible diversions between container and host.

From a maintainers PoV I totally get that. From a users point of view, having these pasta options permanently applied in my containers.conf, afaict, implies that I can no longer create a "vanilla" pasta override through the podman CLI, though. It will only add to what's already configured (unless I misunderstand something here), which will likely add a whole bunch of new problems in the future.

My usecase

Since you asked, I thought I might share my usecase for why I need this and why --network=none doesn't really solve my problem. I spend about between 1 and 1.5 hours every day driving to work and back home by bus. A while ago I decided to use that time to perform some actual work, although offline. That is because my work laptop doesn't have a cellular modem and I don't feel like draining my own mobile data for this.

I cannot just --network=none my containers because I am starting a lot of my containers through actual shell wrappers (so @Luap99 assumption pretty much exactly describes how I work). That is because I banish a lot of programming languages into containers, which I then run as if I actually had them installed. Take my julia container for example: It requires networking sometimes (i.e. when I need to install packages etc.), but other times it really doesn't.

I mean I could work around this, beyond setting default pasta options in containers.conf by e.g. introducing an environment variable that overrides any --network options in my container wrappers, or by opportunistically checking whether the container launches with networking enabled and retrying with --network=none otherwise. But it's not exactly comfortable and, quite frankly, I got used to the way slirp4netns seemed to just lie to me when I don't have any networking at all. :)

[sbrivio-rh]

This doesn't appear to be the whole truth, though:

$ podman run --rm -it --network pasta:-4,-n,24,-a,10.0.2.100,-g,10.0.2.2,--dns-forward,10.0.2.3,-I,tap0,-M,00:00:00:00:00:00 hello-world
Error: pasta failed with exit code 1:
External interface not usable

Ah, right, we try to validate the upstream interface anyway, but we shouldn't. By the way, if you don't pass a MAC address, we pick 02:00:00:00:00:00 by default (see also this commit). Patches welcome, as always.

It might be slightly more convenient for users in some cases, but I'm not fond of adding more and more possible diversions between container and host.

From a maintainers PoV I totally get that. From a users point of view, having these pasta options permanently applied in my containers.conf, afaict, implies that I can no longer create a "vanilla" pasta override through the podman CLI, though.

No, no, sure, that's something we need to fix in any case. The most complicated part here is to pick a reasonable default, I think.

My usecase

Since you asked, I thought I might share my usecase for why I need this and why --network=none doesn't really solve my problem. I spend about between 1 and 1.5 hours every day driving to work and back home by bus. A while ago I decided to use that time to perform some actual work, although offline. That is because my work laptop doesn't have a cellular modem and I don't feel like draining my own mobile data for this.

I cannot just --network=none my containers because I am starting a lot of my containers through actual shell wrappers (so @Luap99 assumption pretty much exactly describes how I work). That is because I banish a lot of programming languages into containers, which I then run as if I actually had them installed. Take my julia container for example: It requires networking sometimes (i.e. when I need to install packages etc.), but other times it really doesn't.

Thanks a lot for the detailed description. So, if we don't create any interface because there are no connected interfaces on the host, you would need to restart your container once networking is available and needed, which isn't great.

On the other hand, if we just make up addresses and routes, we'll make issues like #22197 even worse, because if networking is not available yet, we'll behave like slirp4netns, forcing NAT, instead of refusing to start, which users have a chance to notice.

At this point, I think we have another case for monitoring netlink events on the host, and create (and possibly delete, I'm not sure) connected interfaces in the container only as they appear on the host (again, that's just a default).

If you have no connectivity, your container would start with lo only, then interfaces and addresses would appear as soon as there's something connected on the host. Or, if the host has just one non-loopback interface, we could create it right away in the container, but without addresses and routes, until they appear on the host.

I was already thinking about a mechanism like that to support something similar to https://bugs.passt.top/show_bug.cgi?id=48, where we would share an IPv6 prefix with containers, and IPv6 addresses wouldn't need to be explicitly configured on the host. If the prefix changes, though, we would need to advertise a new prefix to the containers as well.

In any case, this needs to wait until we implement a full-fledged flow table. But perhaps we can slightly improve things meanwhile, at least by not validating the upstream interface if all the information is there. Again, patches welcome, for this and for any other possible improvement.

[Luap99]

At this point, I think we have another case for monitoring netlink events on the host, and create (and possibly delete, I'm not sure) connected interfaces in the container only as they appear on the host (again, that's just a default).

If you have no connectivity, your container would start with lo only, then interfaces and addresses would appear as soon as there's something connected on the host. Or, if the host has just one non-loopback interface, we could create it right away in the container, but without addresses and routes, until they appear on the host.

While I agree that this would be useful it would also be very problematic for podman's management of /etc/{hosts,resolv.conf} When the ip in the container changes the entries are now incorrect and can cause further failures.

[sbrivio-rh]

At this point, I think we have another case for monitoring netlink events on the host, and create (and possibly delete, I'm not sure) connected interfaces in the container only as they appear on the host (again, that's just a default).
If you have no connectivity, your container would start with lo only, then interfaces and addresses would appear as soon as there's something connected on the host. Or, if the host has just one non-loopback interface, we could create it right away in the container, but without addresses and routes, until they appear on the host.

While I agree that this would be useful it would also be very problematic for podman's management of /etc/{hosts,resolv.conf} When the ip in the container changes the entries are now incorrect and can cause further failures.

Could conmon implement a netlink monitor (for the container, not for the "host" as pasta would have) if it's the right place? Otherwise, could pasta (or aardvark-dns) help?

[Luap99]

Could conmon implement a netlink monitor (for the container, not for the "host" as pasta would have) if it's the right place? Otherwise, could pasta (or aardvark-dns) help?

conmon development is basically dead, most development is happening for the (new) conmon-rs which is not yet integrated into podman and I am not sure that this is happing any time soon. aardvark-dns does not work as it is not running for a simple --network pasta case, or in other cases where dns is not needed and it doesn't do anything with files in the container.
We could try to teach pasta to edit the files but I don't see how this can work reliably, there are just to many variables that influences these network configuration.

In general our tooling is not designed for changing networking inside the container and I don't see how this could ever happen without major changes. And I already have way to much variables on the networking side so I would be against introducing more complications.