Firewall rule management

Firewall management operates across the Red Hat OpenShift Container Platform (RHOCP) control plane, the Red Hat Enterprise Linux (RHEL) data plane nodes, and the tenant networking layer, each with different security and hardening approaches.

Control plane firewall management
Copy link

The Red Hat OpenStack Services on OpenShift (RHOSO) control plane runs on Red Hat OpenShift Container Platform (RHOCP). You no longer need the ExtraFirewallRules parameter, Puppet-managed iptables rules, and the firewall.yaml Heat template from RHOSP 17.1.

You can enforce control plane network traffic isolation by Kubernetes NetworkPolicies and with the network security primitives in RHOCP. You can define NetworkPolicies in the RHOSO namespace to restrict traffic between pods and limit ingress to API endpoints.

Data plane firewall management
Copy link

Data plane nodes run RHEL 9 and host containerized Red Hat OpenStack Services on OpenShift (RHOSO) services. Host-level firewall management is handled by firewalld, SELinux policies and nftables. iptables is deprecated on RHEL 9.

Unlike in Red Hat OpenStack Platform (RHOSP) 17.1, the EDPM (External Data Plane Management) automation does not automatically deploy a comprehensive set of host firewall rules. You can use standard RHEL firewall tools to harden the data plane nodes, ensuring that only the ports required by OpenStack services such as, compute, networking, and storage traffic are open.

Manage the data plane firewall
Copy link

Data plane nodes run RHEL and host containerized OpenStack services. Use standard RHEL firewall tools to harden the data plane nodes so that only the compute, networking, and storage traffic ports are open.

About this task
Copy link

Host-level firewall management is handled by firewalld, SELinux policies and nftables. iptables is deprecated on RHEL 9. Manage firewall rules on data plane nodes through the edpm-ansible roles executed by the OpenStack Operator during data plane deployment. The edpm_nftables Ansible role configures nftables on each data plane node. Default rules are applied automatically during the OpenStackDataPlaneDeployment run.

Procedure
Copy link

  1. To add custom firewall rules, add the edpm_nftables_extra_rules variable in the ansibleVars section of your OpenStackDataPlaneNodeSet CR: 
    spec:
  nodeTemplate:
    ansible:
      ansibleVars:
        edpm_nftables_user_rules: |
          - rule_name: '100 Allow Prometheus node-exporter'
            rule:
            proto: tcp
            dport: 9100
          - rule_name: '101 Allow custom application'
            rule:
            proto: udp
            dport: 999 edpm_nftables_userextra_rules:
          - chain: input
            rule: tcp dport 9100 accept
            comment: "Allow Prometheus node-exporter"
          - chain: input
            rule: udp dport 999 accept
            comment: "Allow custom application"
  2. Create a new OpenStackDataPlaneDeployment CR to apply the changes.
  3. To restrict a service to a specific network, such as limiting RabbitMQ access to the internal API network, define a drop rule after the allow rule. The nftables rules are processed in order: 
    edpm_nftables_user_rules: |
  - rule_name: '100 Allow RabbitMQ from InternalAPI'
     rule:
       proto: tcp
       source: 172.17.0.0/24
       dport:
         - 4369
         - 5672
         - 25672
  - rule_name: '101 Drop other RabbitMQ access'
     rule:
       proto: tcp
       dport:
         - 4369
         - 5672
         - 25672
        action: drop

Tenant network firewalls
Copy link

There are different considerations for security groups and Firewall-as-a-Service (FWaaS) in firewalls for tenant networks.

Tenant network firewall for security groups
You can use security groups as the primary mechanism for controlling network traffic to and from instances at the port level. In Red Hat OpenStack Services on OpenShift (RHOSO) 18.0, OVN is the default networking back end so you can implement security groups by using OVN ACLs. Unlike in Red Hat OpenStack Platform (RHOSP) 17.1, the iptables_hybrid and openvswitch firewall driver choice, namely NeutronOVSFirewallDriver, no longer applies. Security groups use a default-deny policy for ingress and permit all egress. In RHOSO 18.0, you can now create stateless security groups in addition to the default stateful behavior. Stateless security groups bypass connection tracking and can offer better performance, but require explicit rules for return traffic and provide less granularity. Use stateless security groups only where applications are highly performance-sensitive or require hardware offloading of OpenFlow actions. You can also use security group logging to audit accepted and dropped traffic per security group, providing visibility for compliance and forensic analysis.
Tenant network firewall for FWaaS
Security groups operate at the instance port level and cannot enforce policy at the router or network level. Security groups can only allow specific traffic, while all other traffic is implicitly denied. For use cases that require L3 firewall policies applied at the router level, ordered rule evaluation, or explicit deny actions, RHOSO 18.0.14 FR4 introduces FWaaS v2 as a Technology Preview. Do not use FWaaS in production environments. FWaaS is implemented as a Neutron service plugin using OVN port groups and ACLs applied to logical router ports. Tenants can define firewall rules, group them into policies with ingress and egress policy separation, and attach firewall groups to specific router ports. This provides tenant-controlled, granular L3/L4 traffic filtering across project networks. You cannot use the neutron-fwaas driver and the log API plugin simultaneously in the same Neutron deployment or else this causes log creation failures. For layered defense, combine security groups at the port-level with FWaaS at the router-level when FWaaS is supported. Regularly audit both security group rules and firewall policies for least-privilege access.

Firewall best practices
Copy link

Apply firewall best practices across your control plane and data plane to reduce your attack surface and enforce the principle of least privilege.

  • Define Kubernetes NetworkPolicies for the Red Hat OpenStack Services on OpenShift (RHOSO) control plane namespace to restrict inter-pod and API ingress traffic.
  • Harden data plane RHEL 9 nodes with firewalld and open only the ports that are required by RHOSO services.
  • Apply the principle of least privilege to security group rules. Review and audit rules regularly.
  • Use the default setting of stateful security groups, unless you require stateless groups for your specific workload.
  • Enable security group logging for compliance auditing and forensic analysis.
  • Enable port security on virtual and direct-physical VM ports to drop any packets that do not meet ipc/mac of the VM.
  • When FWaaS is supported, combine security groups at the port-level with FWaaS at the router-level for layered defense.

RHOSP 17.1 to RHOSO 18.0 firewall comparison
Copy link

RHOSO 18.0 introduces architectural changes when compared to Red Hat OpenStack Platform (RHOSP) 17.1 that require different approaches to firewall configuration and security hardening. The following table summarizes the key differences between the two releases.

Table 1. Firewall updates for RHOSO 18.0
Red Hat OpenStack Platform (RHOSP) 17.1 RHOSO 18.0

ExtraFirewallRules and Puppet-ordered iptables on overcloud nodes.

Control plane uses Kubernetes NetworkPolicies, data plane uses firewalld/nftables on RHEL 9.

NeutronOVSFirewallDriver (iptables_hybrid or openvswitch)

OVN is the only back end, security groups use OVN ACLs natively. You do not need to select drivers.

Security groups are stateful only.

You can have stateful by default, or stateless security groups.

FWaaS not available.

FWaaS v2 is available as Technology Preview in 18.0.14 FR4 for router-level L3/L4 policy.

Deploy with $ openstack overcloud deploy -e firewall.yaml

No heat or director deployment. RHOSO uses OpenStack Operators on RHOCP.

In RHOSP 17.1, the platform deployed and managed host-level firewall rules automatically as part of the overcloud deployment lifecycle. In RHOSO 18.0, the control plane is an RHOCP workload with its own network security model. You are responsible for using standard RHEL tools to harden data plane hosts. Tenant firewalls have moved entirely to OVN-native implementations.