How a NetworkPolicy Blocks a Pod
Every Pod can reach every Pod, so how do you stop one? A NetworkPolicy that selects a Pod for a direction raises a boundary on that Pod in that direction, and from then on everything it does not explicitly allow is dropped there. A connection has to clear a boundary at each end, the egress of the sender and the ingress of the receiver, and the network plugin is what raises them, so a policy nothing implements raises nothing.
Play the animation 6 steps, animated, best on a wide screen
How a NetworkPolicy Blocks a Pod, step by step
-
No policy selects any of these Pods, so no Pod has a boundary and nothing is refused anywhere. Both calls out of web-1 are served, the one to db-1 and the one to cache-1, and no rule exists anywhere that could have stopped either. This is the flat promise the network model opens with.
Play from step 1 -
A NetworkPolicy selects db-1 for Ingress. That selection is the whole act: a boundary now stands on the way into db-1, and everything the policy does not explicitly allow is dropped there. This one allows nothing yet, so the call from web-1 crosses the wire, reaches the boundary and dies inside it.
Play from step 2 -
The same policy gains one ingress rule, from podSelector role=web. Isolation and permission are two different things: selecting the Pod is what raised the boundary, and a rule is what opens a hole in one that was refusing everything. The same call passes through now, and db-1 answers it.
Play from step 3 -
A second NetworkPolicy selects web-1 for Egress, so a boundary appears on the way out of web-1 as well. The same connection is judged twice now, at two boundaries that know nothing about each other: the egress rules of the sender, then the ingress rules of the receiver. Both allow it, so it stands.
Play from step 4 -
Now the same sender calls cache-1, which no policy has ever selected: nothing stands on the way into it and it would take a connection from anyone. It still never happens. The egress rules on web-1 name role=db and nothing else, so the call dies in the boundary it has to leave through.
Play from step 5 -
Neither boundary belongs to the API server. A network plugin watches NetworkPolicy objects and programs the dataplane, and both boundaries here are its work. Where nothing implements NetworkPolicy the API server stores both objects and reports success, no boundary is ever raised, and both calls are served exactly as they were before either object existed.
Play from step 6