Explain network policy as an allow-list

NetworkPolicy expresses permitted traffic for selected Pods under a supporting network implementation. Creating a policy object is not enough if the cluster network does not enforce it. Verify the actual provider and behavior. Policy intent and packet handling are separate pieces of evidence.

Policies are additive. When multiple policies select a Pod for a direction, their allowed traffic is combined. An additional restrictive-looking policy does not cancel an existing broad allow rule. This is a common source of false confidence. Review the effective set of selected policies, not one file in isolation.

Ingress and egress are independent. A connection may require permission at both the source's egress and the destination's ingress when both sides are isolated. A default-deny posture for one direction does not automatically define the other. Namespaces provide organization, but a namespace alone is not a complete network security boundary.

Selectors define sets. Combining a namespace selector and Pod selector in one peer entry differs from writing separate peer entries. The first can mean Pods with the label inside matching namespaces. Separate entries can admit either set. Inspect the actual YAML structure and test from both intended and unintended clients.

DNS and control dependencies are easy to overlook. An application blocked from name resolution can appear to have a downstream service outage. Permit only the required destinations and protocols under the cluster's DNS design, then test. NetworkPolicy usually works at network and transport layers; it does not replace application authorization for individual users, objects or HTTP operations.

Teaching namespace payments contains an API Pod labelled app=invoice-api and a worker labelled app=invoice-worker. The API should accept TCP port 8080 only from the gateway Pods in namespace edge. It also needs egress to a database on TCP 5432 and to the cluster's DNS service. Start by writing the allowed communication pairs in a table. This is easier to review than beginning with a long YAML file.

Now suppose a second policy selects invoice-api and allows ingress from every Pod in payments. The intended gateway-only boundary is no longer the effective policy. The permissions are combined, so the worker can reach the API too. Removing a narrow policy does not fix that broad grant. Find and revise the policy that contributes the unwanted allowance.

Selector structure creates another trap. In one peer entry, namespaceSelector matching edge plus podSelector matching gateway constrains the source to the intersection. In two separate entries, one entry can allow every Pod in edge and the standalone Pod selector can allow gateway-labelled Pods in the policy's own namespace, payments. Those are different source sets. A reviewer should translate YAML into plain set membership before approving it.

Use a disposable namespace or approved test environment. Test the intended gateway connection first, then test an unrelated Pod and a Pod with the same app label in a different namespace. Verify DNS separately from database access. A failed hostname request could be a DNS denial, while a direct-IP connection still works. Record source identity, destination, protocol and observed result for each case.

Test policy changes after the actual network provider has applied them. Eventual propagation and connection handling can make an immediate observation misleading. Existing connections may behave differently across implementations and policy changes, so the test should establish new connections and document what it measures. Do not turn one successful deny test into a claim about every protocol or host-network workload.

Finally, state the authorization boundary above the network. If an allowed gateway forwards a request for the wrong tenant's invoice, NetworkPolicy can still allow the packet because the source and port match. The API must check the authenticated principal and invoice ownership. Network restriction reduces reachable paths; it does not determine business permission.

The interview answer should end with the effective communication matrix and the negative tests. A statement such as 'we have default deny' is only useful when the candidate can identify selected Pods, policy directions, exceptions and enforcement. The matrix also helps operators distinguish an intended denial from a missing dependency allowance.

A second negative test should vary only one selector dimension. Keep the gateway Pod label but place the test Pod in an unrelated namespace. Then keep the namespace label but remove the gateway Pod label. Under the intended intersection rule, both connections should fail. The real gateway should still succeed. This three-case test distinguishes an intersection from a union more clearly than one random denied client. Record new connection attempts rather than reuse a connection established before the policy change. If results disagree with the expected set, inspect effective policies and provider behavior before changing application code. The test evidence should name the exact labels so another engineer can repeat it.

Illustrative peer fragment:

1ingress:2  - from:3      - namespaceSelector:4          matchLabels: {team: edge}5        podSelector:6          matchLabels: {app: gateway}7    ports:8      - {protocol: TCP, port: 8080}

The namespace and Pod selectors are in the same peer entry, so the teaching intent is gateway-labelled Pods in edge-labelled namespaces. A complete policy also needs podSelector, policyTypes and metadata. This fragment does not define egress or prove enforcement by the network provider.

Policy A selects an API and allows ingress from gateway Pods. Policy B selects the same API and allows all Pods in its namespace. A local worker can connect. Is this a policy failure? Give the effective-rule explanation and a negative test.

It can be correct enforcement of the combined permissions. Policy B allows the worker, so policy A does not deny it. Review and remove or narrow the broad grant under the intended contract. Then create a new connection from the worker and from an unrelated namespace, while confirming the gateway still succeeds. Verify the network provider supports the policy. A policy object in the API is not sufficient proof of packet filtering.

Score out of four: one point for the correct result, one for showing the intermediate reasoning, one for identifying the stated failure case, and one for a verification that could disprove the answer. Do not award the reasoning point for a tool name alone.

Misconception 1: a deny-looking policy overrides broad allow policies. NetworkPolicy permissions are additive, so another selected policy can allow the traffic. Misconception 2: network access proves business authorization. An allowed service can still request another tenant's object; the application must enforce that permission.

Evidence class: recommended. Original practice.

Why can a Pod connect even though you added a restrictive NetworkPolicy?

Strong answer: I check whether the provider enforces policies, which policies select both ends, whether a broad additive rule permits the flow, and whether ingress and egress directions match the test. Then I test a new connection from a known identity.

Follow-up: How does placing namespaceSelector and podSelector in separate peer entries change the allowed set?

Weak answer indicators: Treating namespace as complete isolation; reviewing one policy alone; confusing DNS failure with all network failure.

Technical references: Kubernetes NetworkPolicy; OWASP authorization. Sources support the documented mechanisms. The numbers, decisions, rubrics and interview prompts in this lesson are original teaching examples, not measurements or employer question claims.