bc-gov-networkpolicy

To write a Kubernetes NetworkPolicy for BC Gov OpenShift, you must enforce least-privilege network flows by applying the two-policy rule, ensuring both sender egress and receiver ingress policies are created for every traffic flow across Silver, Gold, or Emerald environments.

Inter-namespace communication fails when NetworkPolicy rules are incomplete. You need the two-policy rule to create matching sender egress and receiver ingress policies, plus mandatory DNS egress allowances on port 53 for namespace resolution to succeed.

Yes, you must allow DNS egress for same-namespace NetworkPolicy flows. Mandatory DNS egress reminders ensure applications can resolve internal services, requiring explicit port-specific selectors to prevent silent network failures in BC Gov private cloud environments.

Yes, you can use ag-helm intent API compatibility with OpenShift NetworkPolicy. The Skill provides specific recommendations for ag-helm intent APIs and ensures conformance to ag-devops Conftest gate constraints required for Emerald environment guardrails.

The best way to debug silent network failures is using the provided troubleshooting checklist and oc commands to diagnose NetworkPolicy issues. This validates two-policy sender and receiver rules, DNS port allowances, and CIDR-based external egress configurations.

Yes, this NetworkPolicy approach supports CIDR-based external egress. It provides clear, repeatable patterns for configuring external traffic flows alongside inter-namespace selectors, ensuring secure egress conformance within BC Gov OpenShift clusters.