App Pods are behind a default-deny ingress NetworkPolicy. External users reach the app through an Ingress controller. What additional allow is typically required?
Select an answer to reveal the explanation.
Short Explanation
The Ingress controller is just another client on the Pod network—default-deny means you must allow that controller's Pods to reach the app port. Opening all egress or hostNetwork doesn't invite that inbound knock.
Full Explanation
When app Pods sit behind a default-deny ingress NetworkPolicy, every inbound client path needs an explicit allow—including the Ingress controller path used by external users. The Ingress controller Pods are simply clients on the Pod network that forward HTTP to the app Service port. Therefore you typically must allow ingress from the Ingress controller Pods (podSelector and/or namespaceSelector for the controller’s namespace) to the app Pods on the service/target port. Without that allow, citizens hit the edge successfully in DNS terms but never reach the application.
Allowing only egress from the app Pods to 0.0.0.0/0 does not create inbound permission for the controller. Deleting the Service so the controller can hit Pod IPs still leaves NetworkPolicy ingress evaluation in place and breaks the normal Service-based routing model. Setting hostNetwork on every app Pod is an isolation-weakening bypass, not a correct NetworkPolicy design.
Exam caveat: identify how your cluster labels Ingress controller Pods and which namespace they run in before writing the allow. Operational check: with default-deny alone, confirm external requests fail at the app; add the controller peer allow; retest the civic hostname; kubectl describe networkpolicy and compare with kubectl get pods -n <ingress-ns> --show-labels. Record the allow as a required companion to default-deny for Ingress-fronted municipal apps.