Hello. I have tried Podman in Fedora 31. Not a rootless setup. Software versions: podman-1.6.2-2.fc31.x86_64 containernetworking-plugins-0.8.2-2.1.dev.git485be65.fc31.x86_64 IP and netmask of the Fedora machine in my network: 192.168.5.130/24. Podman creates, on the start of the first container, its default cni-podman0 bridge with IP and netmask 10.88.0.1/16. I wanted to play through a situation when we are migrating from a service (let's say, 9999/tcp) formerly provided by some software installed directly on the host to the same service provided by the same software, but in a podman container. And this software needs to be firewalled: there is a whitelist of IP addresses (let's say 192.158.5.30 and 192.168.5.44) that have the privilege to talk to 192.168.5.130:9999. With the old, non-containerized setup, implementing this kind of whitelist is trivial. Add a new firewalld zone, add thenecessary ports and whitelisted client IPs to it, set the target to REJECT or DROP, done. However, once I switch to a containerized service, the firewall becomes ineffective, because the packets hit the FORWARD chain, not INPUT. I could not find a good solution that works in terms of the exposed port (i.e. 9999, even if inside the container a different port is used). I could either add iptables rules (yuck... firewalld exists for a reason) to "raw" or "mangle" tables (but then I cannot reject), or do something in the "filter" table with "-p tcp -m tcp -m conntrack --ctorigdstport 9999" (that's better). I think that firewald could see some improvement here. In order to apply a whitelist of hosts that can connect, I should not need to care whether the service is provided by something running on the host, or by a container. OK, another crazy idea: is it possible to use slirp4netns instead of the default bridge for root-owned containers, just to avoid these INPUT-vs-FORWARD firewall troubles? -- Alexander E. Patrakov

Alexander, Would this help your case? https://github.com/containernetworking/plugins/tree/master/plugins/meta/f... On Tue, 2019-11-05 at 01:11 +0500, Alexander E. Patrakov wrote: > Forgot the question: what's the current best practice for firewalling > (as in: selectively, by source IP, allowing access to) services > provided by containers on the exposed ports (the "-p" option)? > > вт, 5 нояб. 2019 г. в 01:00, Alexander E. Patrakov < > patrakov(a)gmail.com&gt;: > > Hello. > > > > I have tried Podman in Fedora 31. Not a rootless setup. > > > > Software versions: > > > > podman-1.6.2-2.fc31.x86_64 > > containernetworking-plugins-0.8.2-2.1.dev.git485be65.fc31.x86_64 > > > > IP and netmask of the Fedora machine in my network: > > 192.168.5.130/24. > > Podman creates, on the start of the first container, its default > > cni-podman0 bridge with IP and netmask 10.88.0.1/16. > > > > I wanted to play through a situation when we are migrating from a > > service (let's say, 9999/tcp) formerly provided by some software > > installed directly on the host to the same service provided by the > > same software, but in a podman container. And this software needs > > to > > be firewalled: there is a whitelist of IP addresses (let's say > > 192.158.5.30 and 192.168.5.44) that have the privilege to talk to > > 192.168.5.130:9999. > > > > With the old, non-containerized setup, implementing this kind of > > whitelist is trivial. Add a new firewalld zone, add thenecessary > > ports > > and whitelisted client IPs to it, set the target to REJECT or DROP, > > done. However, once I switch to a containerized service, the > > firewall > > becomes ineffective, because the packets hit the FORWARD chain, not > > INPUT. I could not find a good solution that works in terms of the > > exposed port (i.e. 9999, even if inside the container a different > > port > > is used). I could either add iptables rules (yuck... firewalld > > exists > > for a reason) to "raw" or "mangle" tables (but then I cannot > > reject), > > or do something in the "filter" table with "-p tcp -m tcp -m > > conntrack > > --ctorigdstport 9999" (that's better). > > > > I think that firewald could see some improvement here. In order to > > apply a whitelist of hosts that can connect, I should not need to > > care > > whether the service is provided by something running on the host, > > or > > by a container. > > > > OK, another crazy idea: is it possible to use slirp4netns instead > > of > > the default bridge for root-owned containers, just to avoid these > > INPUT-vs-FORWARD firewall troubles? > > > > -- > > Alexander E. Patrakov > > > -- > Alexander E. Patrakov > _______________________________________________ > Podman mailing list -- podman(a)lists.podman.io > To unsubscribe send an email to podman-leave(a)lists.podman.io

On 2019-11-05 01:00, Alexander E. Patrakov wrote: >Hello. > >I have tried Podman in Fedora 31. Not a rootless setup. > >Software versions: > >podman-1.6.2-2.fc31.x86_64 >containernetworking-plugins-0.8.2-2.1.dev.git485be65.fc31.x86_64 > >IP and netmask of the Fedora machine in my network: 192.168.5.130/24. >Podman creates, on the start of the first container, its default >cni-podman0 bridge with IP and netmask 10.88.0.1/16. > >I wanted to play through a situation when we are migrating from a >service (let's say, 9999/tcp) formerly provided by some software >installed directly on the host to the same service provided by the >same software, but in a podman container. And this software needs to >be firewalled: there is a whitelist of IP addresses (let's say >192.158.5.30 and 192.168.5.44) that have the privilege to talk to >192.168.5.130:9999. > >With the old, non-containerized setup, implementing this kind of >whitelist is trivial. Add a new firewalld zone, add thenecessary ports >and whitelisted client IPs to it, set the target to REJECT or DROP, >done. However, once I switch to a containerized service, the firewall >becomes ineffective, because the packets hit the FORWARD chain, not >INPUT. I could not find a good solution that works in terms of the >exposed port (i.e. 9999, even if inside the container a different port >is used). I could either add iptables rules (yuck... firewalld exists >for a reason) to "raw" or "mangle" tables (but then I cannot reject), >or do something in the "filter" table with "-p tcp -m tcp -m conntrack >--ctorigdstport 9999" (that's better). > There's an open feature request to add a chain for user-specified IPTables rules that act on containers, such that they will be preserved across container start/stop - and I think that without this (which is not yet implemented) you can't reliable manually configure IPTables rules for containers, because start/stop can mangle your rules.

>I think that firewald could see some improvement here. In order to >apply a whitelist of hosts that can connect, I should not need to care >whether the service is provided by something running on the host, or >by a container. > >OK, another crazy idea: is it possible to use slirp4netns instead of >the default bridge for root-owned containers, just to avoid these >INPUT-vs-FORWARD firewall troubles? Yes - this is possible. I believe `--net=slirp4netns` should do this.