From Fedora Project Wiki
Line 106: Line 106:
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** libvirt
** libvirt
libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify.
*** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify.
 
** podman
* podman
*** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify.
libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify.
** docker
 
*** Docker currently does not cooperate with the nftables backend. It currently side-steps firewalld by injecting its own rules in iptables ahead of firewalld's rules. However, with the nftables backend firewalld's rule will still be evaluated. Netfilter in the kernel will call iptables, then nftables for the same packet. This means firewalld/nftables is likely to drop the packet even if docker has iptables rules to ACCEPT.
* docker
*** Proposed fix 1: Docker package should provide a firewalld zone definition that includes the docker interfaces (e.g. docker0). The zone should use the "ACCEPT" policy (firewalld --set-target). This will allow docker's traffic to pass through firewalld/nftables.
Docker currently does not cooperate with the nftables backend. It currently side-steps firewalld by injecting its own rules in iptables ahead of firewalld's rules. However, with the nftables backend firewalld's rule will still be evaluated. Netfilter in the kernel will call iptables, then nftables for the same packet. This means firewalld/nftables is likely to drop the packet even if docker has iptables rules to ACCEPT.
**** Issue 1: If a user has configured a different docker bridge name, then they'll have to manually add the bridge to the docker zone (or firewalld's trusted zone).
 
*** Proposed fix 2: Just like "Proposed fix 1", but instead of adding the zone definition to docker we created a "docker-firewalld" package that has the zone definition. This could be installed by default when docker is installed.
Proposed fix 1: Docker package should provide a firewalld zone definition that includes the docker interfaces (e.g. docker0). The zone should use the "ACCEPT" policy (firewalld --set-target). This will allow docker's traffic to pass through firewalld/nftables.
Issue 1: If a user has configured a different docker bridge name, then they'll have to manually add the bridge to the docker zone (or firewalld's trusted zone).
 
Proposed fix 2: Just like "Proposed fix 1", but instead of adding the zone definition to docker we created a "docker-firewalld" package that has the zone definition. This could be installed by default when docker is installed.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Revision as of 14:50, 28 August 2019


Firewalld Default to nftables

Summary

This change will toggle the default firewalld backend from iptables to nftables. All of firewalld's primitives will use nftables while direct rules continue to use iptables/ebtables.

Owner

Current status

  • Targeted release: Fedora 32
  • Last updated: 2019-08-28
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Firewalld upstream has used nftables as the default backend for the past two minor releases. It is also the default in other distributions (e.g. RHEL-8). This change will bring Fedora in line with upstream.

Using nftables bring many advantages. See firewalld's upstream blog post. It also highlights a few behavioral changes.

Benefit to Fedora

  • Fewer firewall rules (rule consolidation)

All of firewalld's primitives will use the same underlying firewall (nftables) instead of duplicating rules both in iptables and ip6tables. In nftables rules can match both IPv4 and IPv6 packets. This reduces the number of firewall rules by half.

  • firewalld's rules are namespaced

With nftables firewalld's rules are isolated to a "firewalld" table. A separate firewall (or user) can create its own independent ruleset and firewalld will never touch it.

  • Netfilter upstream is focusing on nftables, not iptables

Scope

  • Proposal owners: firewalld (erig0, Eric Garver)

Currently the firewalld package has a Fedora downstream patch to hide the nftables backend. The only firewalld change required is to remove that patch from the package and rebuild.

  • Other developers: libvirt, podman, docker
    • libvirt
      • libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify.
    • podman
      • libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify.
    • docker
      • Docker currently does not cooperate with the nftables backend. It currently side-steps firewalld by injecting its own rules in iptables ahead of firewalld's rules. However, with the nftables backend firewalld's rule will still be evaluated. Netfilter in the kernel will call iptables, then nftables for the same packet. This means firewalld/nftables is likely to drop the packet even if docker has iptables rules to ACCEPT.
      • Proposed fix 1: Docker package should provide a firewalld zone definition that includes the docker interfaces (e.g. docker0). The zone should use the "ACCEPT" policy (firewalld --set-target). This will allow docker's traffic to pass through firewalld/nftables.
        • Issue 1: If a user has configured a different docker bridge name, then they'll have to manually add the bridge to the docker zone (or firewalld's trusted zone).
      • Proposed fix 2: Just like "Proposed fix 1", but instead of adding the zone definition to docker we created a "docker-firewalld" package that has the zone definition. This could be installed by default when docker is installed.
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes