Red Hat OpenShift Container Platform

Policy additivity

NetworkPolicy objects are additive, which means you can combine multiple NetworkPolicy objects together to satisfy complex network requirements.

For example, if you define both an allow-same-namespace policy and an allow-http-and-https policy within the same project, pods with the role=frontend label accept any connection allowed by either policy.

This means the pods accept:

Connections on any port from pods in the same namespace.
Connections on ports 80 and 443 from pods in any namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress

The policy-group.network.openshift.io/ingress:"" label supports OVN-Kubernetes.

To reduce the cluster attack surface and ensure predictable network behavior, Red Hat OpenShift Container Platform enforces least-privilege network policies on critical networking components.

The operators that manage cluster DNS and cluster Ingress automatically install and maintain default "deny-all" NetworkPolicy objects in their respective namespaces.

Traffic is controlled using targeted "allow" policies in the following namespaces:

DNS component namespaces (openshift-dns and openshift-dns-operator):
- Egress is limited to the API server and required DNS ports.
- Ingress is restricted to essential DNS traffic and metrics.
Ingress component namespaces (openshift-ingress and openshift-ingress-operator):
- Egress is limited to the API server, DNS ports, and route endpoints.
- Ingress is restricted to HTTP/HTTPS traffic and metrics.

Do not run unmanaged or custom pods in these namespaces. Because these namespaces operate on a deny-by-default model, network traffic for any unmanaged containers running in these namespaces will be blocked.