Cross-Namespace NetworkPolicy: the Peer Trap
Control traffic between namespaces with a namespaceSelector, then tighten it to specific Pods — and step around the single most common NetworkPolicy mistake: combining namespaceSelector and podSelector in one peer (AND) versus splitting them into two (OR).
Your mission
NetworkPolicy selectors usually pick Pods by label inside the policy's own
namespace. But real systems span namespaces — a frontend team's Pods calling a
shared api in another namespace — and that's where the namespaceSelector
comes in, and where the single most common NetworkPolicy mistake lives.
An ingress rule's from is a list of peers. Each peer can carry a
podSelector, a namespaceSelector, or an ipBlock. The trap is what happens
when a peer has both a namespaceSelector and a podSelector:
- Both in the same peer → AND. "Pods matching this podSelector that live in a namespace matching this namespaceSelector." Narrow and usually what you want.
- Split across two peers → OR. "Any Pod in that namespace, or any Pod with that label anywhere." Much broader — often a security hole you didn't intend.
The YAML difference is a single dash. One list item with two selectors is AND; two list items is OR. Getting this wrong is the classic exam (and production) failure.
In this lab you open a path from a whole namespace, then tighten it to specific Pods in that namespace — using one peer, not two.
Useful aliases
In your terminal, k is aliased to kubectl and completion is configured. The
jumpbox also has k9s, jq and yq installed.