OpenShift Networkpolicy Security¶

Introduction¶

OpenShift networking troubleshooting starts with pod placement, service endpoints, DNS, and NetworkPolicy. OVN-Kubernetes also makes namespace and pod labels important for policy-driven traffic.

Why This Matters¶

OpenShift adds security defaults such as SCCs, project isolation, and integrated OAuth/RBAC behavior. These protections are useful only when permissions are granted narrowly and verified.

Step-by-Step Configuration¶

oc get networkpolicy -n app

oc describe networkpolicy allow-web-to-api -n app

oc get pods -n app --show-labels

oc rsh deploy/web -n app curl -sS http://api:8080/health

Example output:

NAME               POD-SELECTOR   AGE
allow-web-to-api   app=api        12m

OK

Example YAML¶

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8080

Verification¶

oc get networkpolicy -n app

oc get endpoints api -n app

oc rsh deploy/web -n app -- curl -v http://api:8080/health

Security Best Practices¶

Grant the smallest role or SCC that works, prefer service-account-specific access, keep secrets out of Git, and verify permissions with oc auth can-i.

Common Mistakes¶

• Creating a default deny policy without allow rules.
• Matching namespace labels that do not exist.
• Testing from a pod that has different labels than production traffic.

Troubleshooting¶

Compare the failing user or service account with the role binding, SCC admission error, project quota, or OAuth status shown in OpenShift events.

Related Guides¶

• Openshift Security Context Constraints Explained
• Openshift RBAC Security Explained
• Openshift Security Checklist

Summary¶

OpenShift Networkpolicy Security is safest when permissions are explicit, namespace-scoped where possible, and validated from the same identity that runs the workload.