NetworkPolicy Enforcement & NSX DFW Integration

VCF 9.0Intermediatevcap-advanced⏱ 135 min

Objectives

Deploy front-end and database tiers; enforce NetworkPolicy; verify NSX DFW rule generation.

Prerequisites

VCF lab environment deployed and operational

Lab Environment

Standard VCF lab environment for Advanced VCF 9.0 VKS (vSphere Kubernetes Service)

Tasks

Task 1 NetworkPolicy Enforcement & NSX DFW Integration

Deploy front-end and database tiers; enforce NetworkPolicy; verify NSX DFW rule generation.

Step 1

Deploy app namespace with labels: frontend (web), backend (api), database (db).

Step 2

Deploy test pods in each tier; verify all pods can communicate (no policy yet).

Step 3

Create deny-all NetworkPolicy for ingress.

Step 4

Create allow-policies: frontend ↔ backend, backend ↔ database.

Step 5

Test connectivity: frontend can reach backend, backend can reach database; database cannot reach frontend.

Step 6

In NSX, verify DFW rules created: get firewall rules | grep production

Step 7

Modify policy to add port restriction (backend to database on TCP 5432 only).

Step 8

Retest: Confirm 3306 (MySQL) blocked, 5432 allowed.

Step 9

Extract policy rules to JSON; document L3/L4 mapping to NSX DFW entries.

Validation Gate

Check: Verify lab completion

Expected: Lab exercise completed successfully

Common Errors

Kubernetes NetworkPolicy not enforced because CNI doesn't support it

Fix: On VCF with NSX as the CNI, NetworkPolicy is enforced via NSX DFW rules. However, if the cluster uses a different CNI (e.g., Antrea without NetworkPolicy support enabled), policies are accepted but not enforced. Verify: create a deny-all policy and test connectivity — if traffic still passes, enforcement is not active.

NetworkPolicy allowing ingress but blocking DNS resolution

Fix: A deny-all-ingress NetworkPolicy with specific allow rules often forgets to allow DNS (UDP 53 to kube-dns/CoreDNS). Result: pods can't resolve service names, breaking all service discovery. Always include a DNS allow rule in your network policies.

Not understanding that NetworkPolicy is namespace-scoped

Fix: A NetworkPolicy in namespace-A does not affect pods in namespace-B. Cross-namespace policies require policies in both namespaces. For cluster-wide network isolation, use NSX DFW rules which operate at the VM/vNIC level, below Kubernetes namespace boundaries.

Final Validation

Lab completed successfully

✓ All steps completed → No errors observed

Cleanup / Restore

• Revert to snapshot if needed

Design Reflection (VCDX)

NSX-DFW integration with Kubernetes NetworkPolicy demonstrates defense-in-depth. VCDX panelists test how you layer K8s NetworkPolicy with NSX DFW for comprehensive micro-segmentation.

⚠ Known Pitfalls (from Community KB)

Creating deny-all policies without DNS allow — breaks all service discovery.

Assuming NetworkPolicy works cross-namespace — it's namespace-scoped by design.

Mark complete