Make it possible for non root user to restrict / filter the network communications of podman containers following custom rules

[jerabaul29]

Feature request description

I am running as a non-admin of my host machine a podman container that contains secrets that I need to protect.

This podman container never needs to accept any ingress, and only needs to have egress with a specific IP address that I fully trust. Therefore, I would like podman to filter the traffic in and out of my container, blocking all incoming traffic, and allowing outgoing traffic only to the trusted IP while blocking all other outgoing traffic. This is more restrictive than the firewall rules of the host machine. This way, even in the unlikely event where the container is compromised / someone pushes a malicious base image, the container cannot for example exfiltrate the secrets.

It looks like I could achieve this if I was root on the host machine, by setting up a virtual network, configuring iptable or similar rules for it that match my needs, and use this virtual network as the network for my container. However, I am not admin on the host, so I cannot configure iptable rules at the host level.

Any way podman itself could somehow filter network traffic in and out of the container, at the "boundary" of the container and in a way I can as a non root configure, independently (and in addition) of the host firewall that I cannot configure?

Suggest potential solution

I would like podman to filter traffic in and out of my container, at the "boundary" of the container or its virtual network in a way I can configure as a non admin user, independently of host level iptables and similar which I cannot myself configure.

Have you considered any alternatives?

If I had been admin on the host, I could set up iptable or similar rules on a custom virtual network and use this as the container network. However, I am no admin on the host.

[Luap99]

To do that you would need to join the network namespace and add the firewall rules inside container basically. That is however only safe as long as the container doesn't get CAP_NET_ADMIN.

I would consider such request outside of the scope of podman. There is just to much complexity in creating custom firewall rules and how they get exposed to users.

You can already do this yourself by using oci-hooks that trigger on before the start of the container to add the rules automatically or write your own netavark plugin that manages the network creating fully https://github.com/containers/netavark/blob/main/plugin-API.md

[jerabaul29]

Thank you! I need to read a bit more to fully understand your answer :) . A few questions meanwhile:

To do that you would need to join the network namespace and add the firewall rules inside container basically.

But then would this rules live inside the container (I would prefer to avoid this), or outside of the container and somehow inside the virtual network?

That is however only safe as long as the container doesn't get CAP_NET_ADMIN.

This is the default, right? :)

You can already do this yourself by using oci-hooks that trigger on before the start of the container to add the rules automatically

But that will be injected inside the container, right? Or can these rules apply to the virtual network "outside" the container, to which the container connects? Do you have pointers to examples related to the network filtering / firewalling I am looking for? I search but could not find.

or write your own netavark plugin that manages the network creating fully https://github.com/containers/netavark/blob/main/plugin-API.md

I could not find documentation about if / how one can filter traffic according to a user spec by configuring netavark; do you have pointers to examples?

[jerabaul29]

I was looking into the netavark firewall code; do I understand correctly that this under the hood does call to iptables through the iptables crate? Then I suppose that I will there too have the problem that I wont be able to set up the rules I want without being root?

[Luap99]

Thank you! I need to read a bit more to fully understand your answer :) . A few questions meanwhile:

To do that you would need to join the network namespace and add the firewall rules inside container basically.

But then would this rules live inside the container (I would prefer to avoid this), or outside of the container and somehow inside the virtual network?

For the default case (--network pasta) there is only the container netns and the host netns, pasta doesn't have any sort of firewall so the only way (if you cannot add them on the host) is to add them into the container.

That is however only safe as long as the container doesn't get CAP_NET_ADMIN.

This is the default, right? :)

Yes unless you use --privileged or --cap-add CAP_NET_ADMIN to add them explicitly the container should not have it.

You can already do this yourself by using oci-hooks that trigger on before the start of the container to add the rules automatically

But that will be injected inside the container, right? Or can these rules apply to the virtual network "outside" the container, to which the container connects? Do you have pointers to examples related to the network filtering / firewalling I am looking for? I search but could not find.

The outside is the host using normal layer4 tcp/udp sockets, there is no virtual network outside of the container really.

Now there is a special case for named (custom) networks (alas stuff setup with netavark) which uses an intermediate namespace called "rootles-netns", see #22943 (comment)
so if you use these networks you could put the firewall rules into that namespace using podman unshare --rootless-netns but keep in mind the namespace only lives as long as there are active users of it. So once all containers using it exit it will be removed by podman and on the next start created again. You would need to inject the firewall rules each time it is created and there are no hooks to do that.

The best thing would be to podman unshare --rootless-netns add the rulese there and then sleep inf to keep the podman process alive forever which then keeps the namespace around

or write your own netavark plugin that manages the network creating fully https://github.com/containers/netavark/blob/main/plugin-API.md

I could not find documentation about if / how one can filter traffic according to a user spec by configuring netavark; do you have pointers to examples?

You need to implement the full network management yourself there, see the bridge driver with its firewall interfaces in the netavark repo.

[Luap99]

I was looking into the netavark firewall code; do I understand correctly that this under the hood does call to iptables through the iptables crate? Then I suppose that I will there too have the problem that I wont be able to set up the rules I want without being root?

No you have full privs over the rootless network namespace since we run in a usernamespace. (compare unshare -rn as user, you can create any firewall rules you want there)

[jerabaul29]

Thank you so much for your explanations, this is very interesting though way above my level of competence, I will read more and try to digest this / play around more :) .

Should this be moved into a discussion? :) I feel like we may exchange back and forth a bit in this thread and there may be information useful to other readers :) .

[jerabaul29]

I think I understand what you mean 🎉 🤯 🤓 🙇 . Writing the stuff below to check my understanding is correct :) .

• as you show in rootless podman network architecture diagram? #22943 (comment) , in rootless, there is a namespace "in the middle" between the container and the host - #MatrixTrainmanEnvironment to take an analogy :)
• this is what you point me to with the commands you showed above; i.e.:

mypc:~> podman unshare --rootless-netns
mypc:~ # lsns -t net
        NS TYPE NPROCS    PID USER    NETNSID NSFS                                                                                                 COMMAND
4026531840 net       3 240458 root unassigned                                                                                                      catatonit -P
4026534557 net       2 509692 root unassigned /run/user/434680/netns/rootless-netns-2f33a68e9ffaffd947c8                                           /bin/bash
                                              /run/user/434680/libpod/tmp/rootless-netns/run/user/434680/netns/rootless-netns-2f33a68e9ffaffd947c8 
mypc:~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
mypc:~ # touch test
mypc:~ # ls -lrth test
-rw-r--r-- 1 root root 0 sep.  17 16:55 test
mypc:~ # exit
exit
mypc:~> iptables -L
iptables v1.8.10 (nf_tables): Could not fetch rule set generation id: Permission denied (you must be root)
mypc:~> ls -lrth test
-rw-r--r-- 1 username username 0 sep.  17 16:55 test

This shows that:

• with podman unshare --rootless-netns, I change namespace to get into this "in the middle" namespace; I can see that among the current namespaces is the rootless-netns that you had drawn in your diagram
• while being there, I have local root rights in this namespace, like now I can use iptables, which I cannot when I get back to being a normal user
• still, if I do any action while in this namespace that e.g. creates a file, from within the namespace is appears like root, but when I am outside, it appears again like being done by my usual user.

This is a bit of a brainmelt for me, but I suppose this is just putting the finger on what container technology is all about i.e. leveraging namespaces, right? :) I had used / read quite a bit about container technology over the years and had some superficial understanding of it as an end user, but I think now I just got the revelation of what it looks like deep down and first time I can really put the finger on it myself and not as an end user - thank you so much! :)

[Luap99]

This is a bit of a brainmelt for me, but I suppose this is just putting the finger on what container technology is all about i.e. leveraging namespaces, right? :)

Yes though in particular this is about the user namespace which makes rootless container possible in the first place. We can create that namespace map the host uid (e.g. 1000) to 0 inside the namespace and that then gives us the ability to use (namespaced) capabilities for any namespaces we created within that user namespace. So that is what makes iptables -L work because what the kernel really checks is not that you are root but that you have CAP_NET_ADMIN in the owning user namespace of the netns. When you run just podman unshare without --rootless-netns then it puts you into the user namespace + mount namespace that podman uses internally but you still are on the host network namespace and if you try to run the iptables command there it fails because obviously we do not "own" that one.Everything else would be a major security problem as the normal user could just configure the host level firewall.

Now in terms of capabilities and namespaces there are quite some interactions one should be aware of, I wrote a while about it https://blog.podman.io/2023/12/interaction-between-user-namespaces-and-capabilities/

[jerabaul29]

Trying to summarize a bit the options available, and to make sure I understand everything correctly :) . Sorry for the repetition with stuff above, this is all very new to me :) .

option 1: firewall rules on an individual container basis

To do that you would need to join the network namespace and add the firewall rules inside container basically. That is however only safe as long as the container doesn't get CAP_NET_ADMIN.

You can already do this yourself by using oci-hooks that trigger on before the start of the container to add the rules automatically or write your own netavark plugin that manages the network creating fully https://github.com/containers/netavark/blob/main/plugin-API.md

So if I understand correctly, this would put the firewall rules inside the namespace of each individual container network, and the code running in each individual container will not be allowed to change these as long as there is no CAP_NET_ADMIN rights. This can be done either using oci-hooks (I need to find exactly how to do it, but sounds like this should already be possible to do out of the box with writing the correct script; this should look just like a usual bash iptables rules setting script though, so should be no special difficulty?), or with a netavark plugin but then I would need to write this myself (maybe more complicated?). This would allow to set up firewall rules on each container network individually, with different rules for each container possibly i.e. high granularity. Is this correct? :) If so, this is certainly the way I should try to go :) .

If I understand correctly, even though the firewall (eg iptables) rules would live in the container network namespace, it would still not be possible for code running inside the container to change these from within the container at runtime (ie bypass these rules) if not CAP_NET_ADMIN is set? So basically no way for a container application to bypass these firewall rules, even though the rules are living in the container network namespace?

option 2: firewall rules in the common rootless-netns namespace

Now there is a special case for named (custom) networks (alas stuff setup with netavark) which uses an intermediate namespace called "rootles-netns", see #22943 (comment) so if you use these networks you could put the firewall rules into that namespace using podman unshare --rootless-netns

The rootless-netns namespace is here as a "middleman" when using containers with named custom networks. I could put firewall rules there too with a bit of "hacking" around. However do I understand correctly that then the firewall rules will apply to all containers started with named custom networks? So I could not have disjoint, "incompatible" sets of rules for several containers running at the same time on the same host using this method, so no granularity?

[eriksjolund]

Just sharing another idea. Connect to the network server beforehand and pass the file descriptor to the container with --preserve-fds. Use --network=none to disable network connectivity.

In one shell do the following steps:

1. Create directory

   mkdir ~/dir
   

2. Create file

   echo hello > ~/dir/file.txt
   

3. Change directory

   cd ~/dir
   

4. Run webserver

   python3 -m http.server --bind 127.0.0.1 8080
   

In another shell do the following steps

1. Create file test.bash containing

   #!/bin/bash
   exec 3<>/dev/tcp/127.0.0.1/8080
   
   podman run --rm --network=none --preserve-fds=1 -q docker.io/library/ubuntu bash -c '
     echo -e "GET /file.txt HTTP/1.1\r\nhost: 127.0.0.1:8080\r\nConnection: close\r\n\r\n" >&3
     cat <&3'
   

2. Run command

   bash test.bash
   

   The following output is printed

   HTTP/1.0 200 OK
   Server: SimpleHTTP/0.6 Python/3.13.7
   Date: Wed, 17 Sep 2025 18:26:18 GMT
   Content-type: text/plain
   Content-Length: 6
   Last-Modified: Wed, 17 Sep 2025 18:18:42 GMT
   
   hello
   

   result: The text hello is printed. In other words, it was possible to use the already established TCP socket that was passed with --preserve-fds

[jerabaul29]

Thanks! This is a neat and interesting idea! :) I have to see if / how this would work in practice, not 100% sure due to some authentication and secret availability considerations, so I think I will ideally try to use the firewalling in container network namespace - busy with other stuff today, but I have this on my list of todos for next week! :)

[sbrivio-rh]

@Luap99 just brought this to my attention, so a quick cross-link here (no additional information, at least not at the moment): https://bugs.passt.top/show_bug.cgi?id=139

[jerabaul29]

Thanks! :) As a note, I want to block all incoming, and all outgoing except to a list of IPs (list of length 1 in my case, but this is a detail :) ), not allow all incoming and block all outgoing except a list of IPs - not that this makes any difference in practice if the result is that full firewalling ability is provided to the user, but just to note :) .