Configure Network Policies and Egress Firewalls for a ROSA Cluster

It is common to restrict network access between namespaces and to control where traffic can leave the cluster. OpenShift implements both with NetworkPolicy and EgressFirewall resources on the OVN-Kubernetes network plugin.

These controls apply the same way on ROSA Hosted Control Planes (HCP) and ROSA Classic. Both architectures run OVN-Kubernetes on the data plane, so the project template, NetworkPolicy, and EgressFirewall objects in this guide work on either cluster type.

When to use this guide

Use this guide when you want a baseline namespace isolation pattern for multi-tenant ROSA clusters:

• Restrict pod-to-pod traffic across namespaces with NetworkPolicy
• Control which external destinations workloads can reach with EgressFirewall
• Automate those defaults for every new project through a project request template

These OpenShift resources complement (they do not replace) AWS edge controls such as security groups, NAT gateways, and transit gateway inspection. Pair EgressFirewall with Egress IP when external allowlists need predictable source IPs. For design rationale, see Network isolation with NetworkPolicies and Egress Firewalls in the ROSA best practices guide.

NetworkPolicy vs EgressFirewall

The two resources operate at different layers. The project template in this guide uses both:

NetworkPolicy in this guide controls ingress only. It does not deny egress. EgressFirewall controls egress to destinations outside the pod network.

OVN-Kubernetes constraints

• Each namespace can have at most one EgressFirewall object.
• Rules are evaluated in order. Place Allow rules before catch-all Deny rules.
• The project template applies only to new projects. Existing namespaces (including openshift-* and kube-*) are unaffected until you apply policies manually.
• For platform-wide rules on supported versions, cluster administrators can also use AdminNetworkPolicy . That is a separate cluster-level layer on top of namespace-scoped NetworkPolicy objects.

Prerequisites

• A ROSA cluster on OpenShift 4.20 or newer. This procedure is identical on HCP and Classic; only cluster provisioning differs:
  • ROSA HCP: Follow the Deploying a ROSA HCP cluster with Terraform guide
  • ROSA Classic: Follow the Deploying a ROSA Classic cluster with Terraform guide
• Cluster administrator access (cluster-admin or equivalent). Creating the project template, patching project.config.openshift.io/cluster, and creating EgressFirewall objects require cluster-admin privileges.
• OpenShift CLI (oc)

Project template

The first step is to create a project template that contains NetworkPolicy and EgressFirewall objects with default deny rules.

1. Look up the cluster DNS service IP. Most ROSA clusters use 172.30.0.10, but confirm on your cluster:

   A deny-all EgressFirewall without a DNS exception blocks name resolution for pods in affected namespaces.

2. Create and apply a project template with default deny rules

   NOTE This template ensures that any new project has an egress policy that allows cluster DNS and denies all other external traffic, plus a network policy that only allows ingress from an Ingress Controller and from pods in the same namespace.

   Do not set metadata.namespace on the NetworkPolicy or EgressFirewall objects. OpenShift assigns the new project namespace when it processes the template ( OCP 4.20 project template guidance ).

   Confirm the template object exists before you continue:

   If this command returns NotFound, oc new-project fails later even after you patch the cluster project config. Re-run the cat <<EOF | oc apply -f - step and fix any apply errors first.

3. Patch the project configuration to use the newly created project template

4. Create a new project to verify the policies

   If you already created the demo project before the template was configured, delete it and wait until the namespace is gone. If the namespace still exists, oc new-project egress-demo prints Already on project "egress-demo" and does not run the template.

5. Verify the policies were created

   Expected results:

   • egressfirewall.k8s.ovn.org/default exists in the demo namespace
   • networkpolicy.networking.k8s.io/deny-by-default exists in the demo namespace
   • Egress firewall status is EgressFirewall Rules applied (check with jsonpath or describe if the table column is not shown)

   If either object is missing, use the manual apply step in the next subsection, then continue with the tests.

If the template did not create policies

Some clusters (including certain ROSA HCP configurations) create the project and admin RoleBinding but skip NetworkPolicy or EgressFirewall objects from the template. Apply the policies directly:

Use DEMO_PROJECT=egress-demo-2 if you created a differently named project.

Test the Network Policy

These tests use oc exec against long-running pods in the target namespace. That keeps traffic in the namespace you intend to test. Avoid oc debug for these checks: recent OpenShift CLI versions create short-lived debug pods with different output formatting.

1. Create test pods in the default and egress-demo namespaces

2. Deploy a sample application and expose it

3. Access the application via its Route from your workstation (should succeed)

   Expected: response body contains Hello OpenShift!

4. Access the application via its Route from the default namespace (should succeed)

   Traffic enters through the Ingress Controller, which matches the allowed NetworkPolicy source.

   Expected: response body contains Hello OpenShift!

5. Access the application via its cluster service from within egress-demo (should succeed)

   Expected: response body contains Hello OpenShift!

6. Access the application via its cluster service from default (should fail)

   Expected: command times out or exits non-zero. No response body.

Test the Egress Firewall

1. Verify external access from the default namespace (should succeed)

   Expected: command prints a public IP address.

2. Verify external access from the egress-demo namespace (should fail)

   Expected: command times out or exits non-zero. No public IP is returned.

Allow specific egress destinations

Production namespaces rarely stay on deny-all egress. Update the EgressFirewall to allow specific FQDNs or CIDR blocks before the catch-all deny rule.

1. Patch the egress-demo namespace EgressFirewall to allow icanhazip.com and keep the DNS exception:

   If you opened a new shell, set CLUSTER_DNS again with the lookup command from the project template section.

2. Verify that the allowed external host is reachable from the egress-demo namespace

   Expected: command prints a public IP address.

3. Verify that other external hosts remain blocked

   Expected: command times out or exits non-zero.

Cleanup

Remove demo resources and, if this was a lab cluster, revert the project template configuration.

1. Delete test workloads and the demo project

2. Remove the custom project template

3. Clear the project request template reference (restores OpenShift default project creation behavior)

   On some OpenShift versions you may need to remove the projectRequestTemplate key with a strategic merge or oc edit project.config.openshift.io/cluster instead. Confirm new project creation behaves as expected after cleanup.