Support request for user defined iptables or iptables off/false, as in Docker Engine

[b1shan]

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

/kind feature

Description

Unlike Docker Engine, Podman does not provide support for turning iptables off or false, such as in dockerd cli or config. Moreover, Podman does not provide a user chain, such as DOCKER-USER, where users can put their own rules with the guarantee that they won't be oven run by Docker Engine.

Ref:
https://docs.docker.com/network/iptables/

[mheon]

This seems like it would need to be done inside of CNI.

[b1shan]

I think having either of the option would be a good start - option to turn iptables off or provide a predefined chain for users. The Podman security model is great, a strategic improvement over Docker Engine. This feature aligns with the security model Podman is pushing for IMO. Without this feature, several users are going to have trouble migrating over to Podman, especially the case of hybrid compute environments. The internet is full of usability issues with dockerd and iptables, before they provided an alternative.

[baude]

@b1shan willing to contribute?

[baude]

@b1shan also note, this would be for rootfull containers only?

[b1shan]

@baude yes, that is an option if this isn't a priority for anyone else at the moment. I am more from the user side, haven't seen the code much or the cni lib. If you all help with pointers where to do what, I can, why not.

[b1shan]

@baude not sure I understand what you mean by rootfull containers. This is for containers exposed on the network - on the host and from outside the host.

[baude]

the networking stack is setup differently when containers are run by root vs a regular user.

[rhatdan]

Right, rootless containers do not do anything with iptables.

[mheon]

We've had more requests for this before (specifically the USER chain)

[b1shan]

Spent a few mins looking at the CNI plugins repo and it seems setting iptables off should be rather straight forward, primarily in bridge and p2p plugins. Supporting USER chain, such as CNI-USER will be a bit of work though.

[b1shan]

A user chain is certainly a cleaner approach though, especially for dynamic workloads.

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

@b1shan @baude Still working on this one?

[rhatdan]

No one seems to have touched this in a couple of months. Is this still something we should have?

[mheon]

Yes, we definitely want to support this. Unfortunately the work is entirely on the CNI side.

[rhatdan]

@mccv1r0 Any chance you could look at this?

[mccv1r0]

Yes, we definitely want to support this. Unfortunately the work is entirely on the CNI side.

Podman would need to have an on/off switch and tell CNI about it's value. Podman would also need to supply any rules to a USER chain. IIRC, the plan was for CNI to let runtime add what they want to firewall via Chain CNI-ADMIN (if not that one, another can be created.)

[rhatdan]

@mccv1r0 @mheon Any progress on this?

[rhatdan]

@baude @mheon @mccv1r0 We are still blocked by CNI?

[github-actions]

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

[github-actions]

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

[github-actions]

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

[mheon]

Ahh. Is the request to completely disable creation of rules? No NAT, even? That seems strange, but if people really want it, OK.

[fansari]

I am not able to start more than one container in my scenario with existing nftables.

There is always this "ERRO[0000] "netavark: code: 1, msg: iptables: Chain already exists" error.

It would be good to be able to prevent podman from touching nftables, iptables or any other firewall.

I have now described my issue here:

#274

In way it is now I cannot use podman root containers anymore.

[fansari]

Today I have put this workaround into the systemd service files which start my containers:

ExecStartPre=/usr/bin/systemctl reload nftables                                                                                                                                                                                               
ExecStartPost=/usr/bin/systemctl reload nftables  

With this I am able to have running containers after rebooting my PC.

This cleans all this extra stuff before and after the start of each container.

A better solution of course would be to be able to disable firewall changes by podman.

I never understood this philosophy anyway although I know it from docker. If docker/podman do firewall changes these changes are lost once the user reloads his firewall for any reason.

In docker I also disable this so I have no issues after reloading my firewall.

[fansari]

As I noticed this also affects "podman build". Without stopping nftables every build fails.

I am using podman with netavark and I hope that this feature will be implemented soon.

[mheon]

Transferring to Netavark

[fansari]

Is there any progress on this?

[Luap99]

no, contributions welcome, see #339 (comment) for a way to implement this

[jkiusAlarus]

Hello,
I do need the feature too (only the firewall_management = true|false part though), as I have my own bridge which podman connects to and Podman insists on natting containers.

As @fansari I added an ExecStartPost statement in the .service file:

ExecStartPost=/usr/bin/remove_netavark_from_nftables.sh

root@jack:~#cat /usr/bin/remove_netavark_from_nftables.sh
#!/usr/bin/bash
/usr/sbin/nft flush chain ip filter FORWARD
/usr/sbin/nft flush chain ip6 filter FORWARD
/usr/sbin/nft flush chain ip filter NETAVARK_FORWARD
/usr/sbin/nft flush chain ip6 filter NETAVARK_FORWARD
/usr/sbin/nft delete chain ip filter NETAVARK_FORWARD
/usr/sbin/nft delete chain ip6 filter NETAVARK_FORWARD
/usr/sbin/nft delete table ip nat
/usr/sbin/nft delete table ip6 nat

unfortunately, I'm a sysadmin and not a dev. It'll be difficult for me to help with the implementation proposed
regards
Laurent

[oskarirauta]

I made a fork of netavark with 2 branches.

Other branch disables firewall completely, and other adds new option none for NETAVARK_FW environment variable to disable firewall features. Though, I wasn't able to use it the way I wanted, most likely a wrapper script could work out. Such wrapper script could be for example like this:

#!/bin/sh
NETAVARK_FW="none" /usr/bin/netavark-bin $@

I first tried to make it possible to activate it through /etc/containers/networks/{network_name}.json but unfortunately it seems that firewall driver is decided before processing network configuration, so there is no chance to set firewall driver per network basis unless making larger changes.

firewall completely disabled branch
firewall with new option to NETAVARK_FW

fwnone firewall driver is just a dummy firewall driver, that has firewalling features as iptables / firewalld would have, but it does not do anything, just always returns that query for firewall succeeded perfectly :)

This though isn't useful to do a PR for netavark, unless maybe for option that uses environment variable possibility.. Someone else should be more valid to decide if this is something that is useful in mainstream or not. Anyway- for those who need it. Well, for those looking forward to this feature supported in mainstream, I hope this is useful during "waiting period".
Even though that "stub" method talked about is here..

EDIT:
After thorough testing, I can verify that podman + netavark is fully usable on openwrt, so it should be full working also on any other environment where you want to control firewall features manually (or not control them at all). Hopefully mainstream will be acquiring this feature soon.

EDIT2:
value fwnone for NETAVARK_FW was renamed none

[Luap99]

@oskarirauta I think it makes sense to upstream the NETAVARK_FW option, we then can add a option to containers.conf to allow setting this value via config file and podman would just set this env when calling netavark.

Although I would prefer to call this option none instead of fwnone

[oskarirauta]

@Luap99 I was thinking exactly the same thing and can surely change it - even though I think this should be just a proof of concept and be re-done by maintainers, this was the first time I did anything in rust- so even though it works, I think experts might want to change some things..

I also sent a feature request to podman maintainers, since I did not found one before- for them to add support to such feature...

[oskarirauta]

@Luap99 I renamed it from fwnone to none

[coredump17]

Is this request to add all rules inside a chain, similar to DOCKER and give a USER chain priority to give the user control of what outside traffic they allow in ? It's not totally clear as the thread then talks about disabling firewall function all together.

[fansari]

What I want is to have the same behaviour as this would do in docker:

/ec/docker/daemon.json

{
  "iptables": false
}

Which means that docker does not do any changes to the firewall rules of the system.

The user then has to do everything he needs for docker on his own (e.g. defining masquerade rules for NAT).

I could not find a way to achieve this in podman except for scrpting around in each and every container I control with systemd (see above). It would be much appreciated from my side if I finally could ge rid of this.

[oskarirauta]

Because there is no such feature implemented. Set a environment variable instead to disable firewalling features.Lähetetty iPhonestaFrank Ansari ***@***.***> kirjoitti 30.5.2023 kello 19.19: What I want is to have the same behaviour as this would do in docker: /ec/docker/daemon.json iptables: "false" Which means that docker does not do any changes to his firewall rules. The user then has to do everything he needs for docker on his own (e.g. defining masquerade rules for NAT). I could not find a way to achieve this in podman except for scrpting around in each and every container I control with systemd (see above). It would be much appreciated from my side if I finally could ge rid of this. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Luap99]

The work here in netavark was done by @oskarirauta, you can set NETAVARK_FW=none to have that.

What is missing is a containers.conf option for that: containers/common#1338.
But please refrain from making pointless comments there. If there are questions about how to implement it I am happy to answer. If you just want this feature simply use the thumbs up function.
I see if I find some time in the future but in the meantime I welcome anybody to make a PR in c/common to add the new config field and pass it down to netavark.

Thus I am closing the issue here.

[fansari]

Finally it works for me.

I have put this into /etc/containers/containers.conf

[network]
network_backend = "netavark"
firewall_driver = "none"

Now netavark no longer tries to put its own rules into my nftables chain.

Tested with:
podman-5.0.1-1.fc40.x86_64
netavark-1.10.3-3.fc40.x86_64