-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Package Request: firewalld #1747
Comments
Have you tried running it from a privileged container? |
I haven't but I'll try. Is there any documentation, other than the official one from Podman that you can direct me to? |
The dependency list here seems large as this would be the first new package to include python. If we can get past that I think the question to ask ourselves is if we think this is basic functionality we have been missing or not. I think Another way to ask this question is: if |
Another point to mention here: In most cloud environments users most likely rely on cloud firewalling (i.e. security groups) so this is of limited use there. Where this is important is bare metal use cases or more loosely managed or unmanaged environments. |
This is my main reason for the request. I'm not sure how many of the FCOS deployments are on bare metal or home servers/labs. Adding An additional benefit would be the availability of Python, which would allow management of FCOS nodes by Ansible out of the box. |
We decided during today's FCOS meeting to postpone this discussion until the next meeting to ensure more participants, many of whom are currently attending DevConf, can join. |
Just playing around with running it in a container, it seems to work fine in some quick tests: FROM quay.io/fedora/fedora:40
RUN dnf install -y systemd firewalld && \
dnf clean all && \
systemctl enable firewalld
CMD ["/sbin/init"]
You'd probably want to mount e.g. Of course though a downside of this is when provisioning you'd start with no firewall until you can download and start up the container. Though OTOH the list of services that listen by default is quite limited and actively checked in CI. And of course there's also layering eventually if you just want it on the host. So I think the more important question is:
I think it'd be nice to have built-in, but I don't see it as essential IMO. Yes, bare metal is a primary target, but it's hard to ignore that it'd just sit there taking up space on disk and in transit in cloud instances. Also ISTM like a firewall is not so much for our built-in services (yes, could make sense to e.g. IP-restrict incoming SSH connections, but...) but rather services coming from layered packages/derived builds, or containers with exposed ports. At that point, one could choose to also layer firewalld or run it in a container. |
On Fedora CoreOS, we expect users to run their services inside containers. When you run applications inside containers, those are connected to an local internal network by default and are not exposed to the network. You usually control which ports are exposed to the network using the This means that adding any firewall configuration for incoming connections will usually duplicate those container runtime configuration, without any additional security benefit. As far as I know, neither podman nor docker interacts with firewalld. I found https://fale.io/blog/2023/02/24/podman-ports-and-firewalld (but I did not dig deeper). Firewalld is mostly designed around a set of pre-defined rules for well-known services with known-in-advance ports to open. This often do not apply to services running in containers as those may listen on any port or you may publish ports from the container network to different ports on the host and thus to different ports than the ones that are expected by the firewalld configuration. As far as I know, Firewalld does not manage outgoing traffic (https://serverfault.com/questions/618164/block-outgoing-connections-on-rhel7-centos7-with-firewalld, https://www.ispcolohost.com/2016/07/25/blocking-outgoing-ports-with-firewalld/) thus setting this up is very similar to setting iptables/nftables rules manually. Overall, I see very little use cases where firewalld would bring something useful to Fedora CoreOS right now, so I don't think we should include it by default. Layering it or running it from a privileged container should cover the cases where it's a good fit. |
Hi everyone. Firewalld maintainer speaking. I hope I can clarify some points here.
I hope so! The entire firewalld testsuite runs inside of network namespaces. Additionally the upstream testsuite has a few "check container" targets that run via podman/docker.
Both do to varying degrees. The latest Podman has native firewalld support (marked experimental). Older podman had partial integration. Docker has partial integration. Partial integration basically means "do most of the work in iptables, but also interact with firewalld enough to open a hole".
This topic has come up a lot. I've discussed it with the podman team many times. The short is that many users expect "magic" and others expect "strict". Changing that behavior would break many people. I wrote this blog for those that want "strict". https://firewalld.org/2024/04/strictly-filtering-docker-containers
This is exactly why
It has since v0.9.0 (2020). |
Thanks for chiming in! I also see now https://quay.io/repository/firewalld/firewalld. (I had checked before doing my own testing for an official image on Docker Hub and missed checking Quay.io as well.) I was surprised by that
Is there a fundamental limitation there or do you expect it to work if the container is exposed enough? |
The upstream README talks about this.
No. It just requires more work, e.g. dbus configuration on the host. Which then becomes a non-self contained container image. That kind of defeats the purpose, IMO. |
This was discussed at the Fedora meeting yesterday. Summary: Currently, we are not considering adding firewalld by default. We will however add documentation detailing the rationale for this, as well as every port open by default, example nftables configs, and instructions on how to add firewalld to the host. |
@travier captured the documentation bits in coreos/fedora-coreos-docs#247 (comment). So I think we can close this? Feel free to reopen if I'm missing something. |
What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)
What is the size of the package and its dependencies?
What problem are you trying to solve with this package? Or what functionality does the package provide?
firewalld
provides advantages overiptables
/nftables
such as dynamically managed firewall, ability to not care what the backend is, support for network/firewall zones, etc.Can the software provided by the package be run from a container? Explain why or why not.
Yes, in Kubernetes environments as part of a security stack.
Can the tool(s) provided by the package be helpful in debugging container runtime issues?
Yes, indirectly if enabled.
Can the tool(s) provided by the package be helpful in debugging networking issues?
Yes.
Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.
firewalld
can be installed both when first booting via Ignition and later.In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?
N/A
Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS?
No.
Does the software provided by the package have a history of CVEs?
Yes.
The text was updated successfully, but these errors were encountered: