10:51 a.m.
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
3:19 p.m.
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
3:55 p.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
7:43 p.m.
On 5/26/20 1:51 AM, Felder, Christian wrote:
When using podman run -p … DNAT rules in the forward chain are
automatically created for allowing traffic to the container/pod.
I think you might be mixing up two different things. When I run "podman
run -p" I see a new rule in the PREROUTING chain of the "nat" table. I
don't see any rules in the FORWARD chain of the "filter" table.
There are no DNAT rules in the FORWARD chain.
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.
That isn't true on my system, as far as I can tell.
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.
Why wouldn't it allow ssh tunneling?
1425
days inactive
1425
days old
3 comments
3 participants
participants (3)
-
Brent Baude -
Felder, Christian -
Gordon Messmer