Network Isolation

This folder is designed to provide a network administrator with templates and a guide to controlling traffic to workloads deployed in OpenShift. It is designed around restricting ingress, but the same concepts and templates can be extended to egress as well.

Network Policies

NetworkPolicies in OpenShift are used to control network traffic on the cluster pod network (default is 10.128.0.0/14), such as for containerized workloads and OpenShift platform components.

Multi-Network Policies

MultiNetworkPolicies in OpenShift are used to control network traffic on secondary networks, such as the physical network being used for VMs. For this reason, pods and VMs can be thought of as interchangeable in this environment.

They are additive so traffic will be allowed as long as there is at least one policy that allows that connection. Otherwise, traffic is denied.

For each template, the metadata section should be updated for the namespace where the MultiNetworkPolicy will be applied, along with a descriptive name.

Key	Format of Value	Description
k8s.v1.cni.cncf.io/policy-for	Namespace/NetworkAttachementDefinition	The namespace-scoped NetworkAttachmentDefinition (NAD) that this policy will be configured for
name	<action>-<source>-2-<destination>	action is either allow or deny; source is the "from" (e.g. namespace name) and type (e.g. ips) ; destination is the "to" namespace
namespace	Namespace	Namespace where this policy will be deployed

For example, the metadata section for a MultiNetworkPolicy that allows traffic from pods in the project1 namespace by IP address to the project2 namespace would look like this:

metadata:
    annotations:        
        k8s.v1.cni.cncf.io/policy-for: project1/vlan410-project1
    name: project1-ips-2-project2
    namespace: project2

Specific details for each MultiNetworkPolicy template in this folder are explained below:

deny-all-2-namespace.yaml Template

This template should be added to each VM namespace to deny all ingress to all pods in the namespace, unless explicitly allowed by another MultiNetworkPolicy.

allow-from-ips-2-namespace.yaml Template

This template is used to allow traffic from a set of source IP addresses to all pods in a namespace. These source IP addresses can be any combination of internal and/or external, but separate MultiNetworkPolicies should be used to logically separate rules for easier management.

For example, one MultiNetworkPolicy in each namespace should be created to allow all pods in the namespace to be able to communicate with each other. In that case, the from section should include IP addresses for all of the pods in each namespace.

allow-from-ips-2-namespaceexceptpodlabel Template

This template is used to allow traffic from a set of source IP addresses to all pods in a namespace EXCEPT a subset of pods, based on one or more pod labels. These source IP addresses can be any combination of internal and/or external, but separate MultiNetworkPolicies should be used to logically separate rules for easier management.

allow-from-ips-2-podlabel.yaml Template

This template is used to allow traffic from a set of source IP addresses to a subset of pods in a namespace, based on one or more pod labels. These source IP addresses can be any combination of internal and/or external, but separate MultiNetworkPolicies should be used to logically separate rules for easier management.

Observing and Auditing Network Controls

Reviewing Logs for Network Allows and Denies

Cluster logs, including network allows and denies, can be accessed and searched through the OpenShift UI. When logged in as a user with view access to the openshift-ovn-kubernetes namespace, using the "Administrator" view in the top left, go to the Observe section on the left sidebar and select Logs.

From the "Type" dropdown that defaults to "application," select "infrastructure". In the "Search by Content" field, enter either nw_src=<sourceIP> or nw_dst=<destinationIP> with either the source or destination IP address to search by.

Below is an example log message with a breakdown of the most important pieces of information:

2025-10-28T22:44:00.419Z|16244462|acl_log(ovn_pinctrl0)|INFO|name="NP:project2:Ingress", verdict=drop, severity=debug, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=00:1a:2b:3c:4d:5e,dl_dst=9c-B6-d0-8e-f0-a1,nw_src=192.168.1.10,nw_dst=192.168.1.11,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

Value	Description
2025-10-30T06:21:00.419Z	Time and date that the log message was generated
verdict=drop	Whether the connection was allowed or dropped
name="NP:project2:Ingress"	Name of the ACL (access control list)
dl_src=00:1a:2b:3c:4d:5e	MAC Address of the Source
dl_dst=9c-B6-d0-8e-f0-a1	MAC Address of the Destination
nw_src=192.168.1.10	IP Address of the Source
nw_dst=192.168.1.11	IP Address of the Destination

Checking if a Connection is Allowed or Denied by a NetworkPolicy

Note this only works for NetworkPolicies, not MultiNetworkPolicies.

1. Retrieve your OpenShift authentication token:

oc whoami -t

2. Create a debug pod on a worker node:

oc debug node/worker01.example.com	

3. Gain access to host binaries:

chroot /host

4. Log into the OpenShift CLI with your authentication token from Step 1:

oc login --token=<openshift-auth-token-from-step-1> --server https://api.example.com:6443

5. Change the current project to the openshift-ovn-kubernetes project:

oc project openshift-ovn-kubernetes

6. Get the list of pods in this project:

oc get pods -o wide

7. Change directory to the core user's home directory:

cd /home/core

8. Copy the ovnkube-trace from any pod from step 5:

oc cp <ovnkube-node-XXXXX>:/usr/bin/ovnkube-trace ovnkube-trace

9. Make the copied binary executable:

chmod +x ovnkube-trace

10. Use the ovnkube-trace tool to check if NetworkPolicies will allow the connection from a pod to another pod:

./ovnkube-trace -tcp -src-namespace <source-namespace> -src <source-pod-name> -dst-namespace <destination-namespace> -dst <destination-pod-name> -skip-detrace

Checking OVN-Kubernetes Software-Defined Networking Configuration

Note these commands are only relevant for NetworkPolicies, not MultiNetworkPolicies.

Show all objects in OVN:

ovn-nbctl show

Show logical routers:

ovn-nbctl lr-list

Show logical switches:

ovn-nbctl ls-list

List logical switch ports:

ovn-nbctl lsp-list ${logical-switch-name}

A portgroup is created for each NetworkPolicy, and all pods selected by the podSelector of that NetworkPolicy are added to the portgroup's port list.