Red Hat OpenShift Container Platform

Limitations of an egress firewall

An egress firewall has the following limitations:

No project can have more than one EgressFirewall CR.
Egress firewall rules do not apply to traffic that goes through routers. Any user with permission to create a Route CR object can bypass egress firewall policy rules by creating a route that points to a forbidden destination.
Egress firewall does not apply to the host network namespace. Pods with host networking enabled are unaffected by egress firewall rules.
If your egress firewall includes a deny rule for 0.0.0.0/0, access to your Red Hat OpenShift Container Platform API servers is blocked. You must either add allow rules for each IP address or use the nodeSelector type allow rule in your egress policy rules to connect to API servers.

The following example illustrates the order of the egress firewall rules necessary to ensure API server access:
```
apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace>
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny
```
where:

<namespace>

Specifies the namespace for the egress firewall.

<api_server_address_range>

Specifies the IP address range that includes your Red Hat OpenShift Container Platform API servers.

<cidrSelector>

Specifies a value of 0.0.0.0/0 to set a global deny rule that prevents access to the Red Hat OpenShift Container Platform API servers.

To find the IP address for your API servers, run oc get ep kubernetes -n default.

A maximum of one EgressFirewall object with a maximum of 8,000 rules can be defined per project.
If you are using the OVN-Kubernetes network plugin with shared gateway mode in Red Hat OpenShift Networking, return ingress replies are affected by egress firewall rules. If the egress firewall rules drop the ingress reply destination IP, the traffic is dropped.
In general, using Domain Name Server (DNS) names in your egress firewall policy does not affect local DNS resolution through CoreDNS. However, if your egress firewall policy uses domain names and an external DNS server handles DNS resolution for an affected pod, you must include egress firewall rules that permit access to the IP addresses of your DNS server.

Violating any of these restrictions results in a broken egress firewall for the project. Consequently, all external network traffic is dropped, which can cause security risks for your organization.

An EgressFirewall resource is created in the kube-node-lease, kube-public, kube-system, openshift and openshift- projects.