3:34 p.m.
Hello Brent,
no, the "firewall" plugin is for a different purpose. It inserts
iptables rules that allow the NATed traffic to containers, or adds the
IP addresses of containers to a configurable ("trusted" by default)
firewalld zone. It offers no way (or at least no obvious way) to say
that 192.168.5.30 can have access and 192.168.5.31 can't.
вт, 5 нояб. 2019 г. в 01:19, Brent Baude <bbaude(a)redhat.com>:
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>:
> > 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
--
Alexander E. Patrakov