9:55 a.m.
Hello,
I fully agree to that but indeed you’re punching a hole into the firewall when using
podman run -p 80:80 …
the port is already open although there is no explicit rule, e.g.
firewall-cmd —add-port 80/tcp
Best
Christian
On 26. May 2020, at 15:19, Brent Baude <bbaude(a)redhat.com>
wrote:
Hello Christian,
We have been around and around on this topic as a team. The best
answer we could come up with is that by default, no binding would
"open" the host to external connections. Meaning, we would not punch a
hole in the firewall to allow ports. We feel that is the
user/administrater's responsibility.
On Tue, 2020-05-26 at 08:51 +0000, Felder, Christian wrote:
> Hello,
>
> I hope this message finds you guys well. I’ve a question regarding
> CNI and podman run’s publish flag (-p).
>
> When using podman run -p … DNAT rules in the forward chain are
> automatically created for allowing traffic to the container/pod.
> Unfortunately this bypasses the input chain which is usually used to
> explicitly allowing external traffic for a specific service/port.
> Using podman run -p … the port is world-wide accessible though.
>
> One solution is to just bind to the loopback interface using -p
> 127.0.0.1:XXX:XXX which will ensure that the port is just available
> on the
> host system but on the other hand this does not allow using ssh
> tunnelling for authorised external access.
>
> What are best practices for having a container's/pod’s port exposed
> to the host but having explicitly control whether this should be
> accessible world-wide or not?
>
> Just note I am using podman on CentOS 8 (podman-1.6.4-
> 4.module_el8.1.0+298+41f9343a.src.rpm)
>
> Thanks in advance.
> Christian
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io