In a normal Kubernetes cluster, every pod can communicate with every other pod and the external world.
Some people see this and say, “Kubernetes is insecure by default.”
After all, there are no restrictions on pod to pod communication!
But that’s a matter of perspective.
Why Kubernetes has an open networking model?
Imagine a large house with ten rooms. The front door is locked, but every door on the inside is unlocked.
Now imagine a prison. The entrance is locked, and internal doors (cells) are locked too.
Kubernetes was built like a house, but some people expect it to be a prison.
Clusters were designed to run many microservices developed by the same company. In other words, Kubernetes was designed to run trusted code.
As Kubernetes grew in popularity, people wanted it to behave like the prison, for valid reasons.
Why restrict pod to pod communication?
Good security limits how much damage can be done, even if a single application is hacked.
Before Kubernetes, we split networks into security zones. We put servers with sensitive data in an inner zone and limited access to them. We put vulnerable webservers in an outer zone and let them communicate with the world. Way back, very long ago, this even meant putting the servers in different rooms. (Or in the same room, with different colored cables hooking them up to different locations.)
In Kubernetes, you can do something similar using NetworkPolicies.
What are Network Policies?
NetworkPolicies limit who pods can communicate with. Communication is allowed only according to pre-defined rules.
NetworkPolicies vs traditional segmentation
There’s one big difference between NetworkPolicies and old-fashioned segmentation: NetworkPolicies are a logical barrier, not a physical one. Pods that aren’t allowed to communicate can still run on the same node.
This makes NetworkPolicies a little weaker than traditional segmentation, but we’ll look at that another time. (You’re subscribed, right?)