Restricting Pod ingress with a NetworkPolicy
NetworkPolicy ingress control.
Create a NetworkPolicy with podSelector app=frontend, policyTypes Ingress, and one ingress from-rule matching podSelector role=api-gateway; requires a CNI that enforces policies.
What's really being asked
Knowing the native primitive for Pod-level firewalling and its important default-deny semantics, plus the CNI dependency.
The full answer
The native resource is NetworkPolicy. You create a policy whose spec.podSelector matches app=frontend, set policyTypes to include Ingress, and add a single ingress entry whose from list contains a podSelector matching role=api-gateway. The crucial behavior: as soon as a Pod is selected by any NetworkPolicy that includes Ingress, that Pod becomes default-deny for ingress, meaning all inbound traffic is blocked except what the policy explicitly allows. So this one policy both isolates the frontend and whitelists only the api-gateway Pods. If you need to scope by namespace too, add a namespaceSelector, since podSelector alone matches Pods in the policy's own namespace.
The mistakes people make
Forgetting that selecting a Pod turns it default-deny, and worrying you must also write an explicit deny rule. Assuming policies are enforced by Kubernetes itself; enforcement is done by the CNI, and plugins like Calico or Cilium are required. Mixing up podSelector (the targets) with the from selector (the allowed sources).
What usually comes next
How to also allow a whole namespace? Add namespaceSelector. What about egress? Add an Egress policyType. What if no CNI supports policy? The policy is silently ignored. Default-deny everything? An empty podSelector with no rules.
A concrete example
A NetworkPolicy in the tenant namespace selects app=frontend, policyTypes Ingress, with one ingress from podSelector role=api-gateway. After applying it on a Calico-backed cluster, a curl from an api-gateway Pod to a frontend Pod succeeds, while a curl from any other Pod times out, since the frontend is now default-deny except for the gateway.
Interview question
After applying a NetworkPolicy that selects app=frontend for Ingress and allows only role=api-gateway, what happens to other Pods' traffic to frontend?
- a.It is still allowed unless a separate deny policy is added
- b.It is allowed only from the same node
- c.Nothing changes until a CNI-independent controller is installed
- d.It is denied, because selecting the Pod for Ingress makes it default-deny except what is allowedCorrect
Why? this is the answer
Selecting a Pod with an Ingress NetworkPolicy flips it to default-deny, so only the whitelisted api-gateway Pods get through; no explicit deny rule is needed. Enforcement does require a policy-capable CNI.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #network-policy
- #security
- #multi-tenancy
- #cni
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles