Chapter 4 said a Pod has an IP and a Service gives a stable name in front of a set of them. It left out the other half: who is allowed to use that IP.
Flat and open
The Kubernetes network model has three rules:
The CNI plugin (Container Network Interface) is the component that makes this true: it hands out Pod IPs and routes traffic between nodes. Flannel, Calico and Cilium are CNI plugins.
What that means
kubectl exec client -n abyss -- nc -zv market-db 5432
kubectl exec outsider -n other -- nc -zv market-db.abyss 5432market-db (10.96.24.23:5432) open
market-db.abyss (10.96.24.23:5432) openA Pod in another namespace reaches the database as easily as its own API does. Namespaces separate names and permissions for the API server; they do not separate traffic. Nothing you have built so far stops a compromised web Pod from opening a connection to the database directly.
Services do not restrict
A Service is a doorbell, not a door. It makes a set of Pods reachable by one name; it never prevents anyone from ringing. The database answers on its Pod IP whether or not a Service exists.
The missing piece
A NetworkPolicy is a firewall rule attached to Pods by label selector. The next lessons build one up: first refuse everything, then allow exactly the connections the app needs, then control what a Pod may call out to.