The Kubernetes Networking Model guarantees that all Kubernetes Pods on a Kubernetes Cluster are able to communicate, that is, able to exchange messages. However, the Networking Semantics change in the presence of Networking Policies from Default Allow for all Pods to Default Deny for selected Pods with Explicit Allow:
The Kubernetes Network permits all incoming and outgoing messages to and from any Pod per default.
However, if there exists some Network Policy selecting a Pod, the Kubernetes Network prohibits all incoming and outgoing messages to and from the Pod per default.
Then, if there exists some Network Policy selecting a Pod and some rule of the Network Policy allowing Ingress or Egress, the Kubernetes Network permits matching incoming and outgoing messages to and from the Pod.
Kubernetes Networking Policies are a core abstraction of Kubernetes: Per Pod, Network Policies determine if an incoming (Ingress) or outgoing (Egress) message is permitted or prohibited by the Kubernetes Network.
Since Kubernetes Pods are arguably the core abstraction of Kubernetes, one may reasonably conclude that Kubernetes Network Policies express allowed traffic flow holistically in terms of Pods e.g. in terms of a set of Pods, the possible source, and a set of Pods, the possible target.
However, this is not how Network Policies work.
A Kubernetes Network Policy determines whether an incoming or outgoing message is either permitted or prohibited.
For two Pods to communicate
A Kubernetes Network Policy Object may be classified as an Ingress or Egress Policy. Note that a Kubernetes Network Policy Object may be an Ingress and Egress Policy at the same time:
Ingress-Policies ≝
{P ∈ Policies : "Ingress" ∈ as-set(Pol.Spec.PolicyType)}
Egress-Policies ≝
{P ∈ Policies : "Egress" ∈ as-set(Pol.Spec.PolicyType)}
As the names imply
IngressRestricted(Pod) ≝
∃ Pol ∈ Ingress-Policies:
Pod.Labels match Pol.Spec.PodSelector
EgressRestricted(Pod) ≝
∃ Pol ∈ Egress-Policies:
Pod.Labels match Pol.Spec.PodSelector
IngressAllowed(Pod, (sAddr, sPort, tAddr, tPort, Proto)) ≝
IngressRestricted(Pod)
⟹
∃ Pol ∈ Ingress-Policies:
∧ Pod.Labels match Pol.Spec.PodSelector
∧ ∃ Rule ∈ Pol.Spec.Ingress:
∧ ∃ Peer ∈ Rule.From:
PeerAllowed
(Peer, sAddr)
# if no port is specified all ports and protocols are allowed
∧ Rule.Ports ≠ ∅
⟹
∃ Port ∈ Rule.Ports:
∧ Port.Protocol = Proto
∧ Port.Port match tPort
EgressAllowed(Pod, (sAddr, sPort, tAddr, tPort, Proto)) ≝
EgressRestricted(Pod)
⟹
∃ Pol ∈ Egress-Policies:
∧ Pod.Labels match Pol.Spec.PodSelector
∧ ∃ Rule ∈ Pol.Spec.Egress:
∧ ∃ Peer ∈ Rule.To:
PeerAllowed
(Peer, tAddr)
# if no port is specified all ports and protocols are allowed
∧ Rule.Ports ≠ ∅
⟹
∃ Port ∈ Rule.Ports:
∧ Port.Protocol = Proto
∧ Port.Port match tPort
PeerAllowed(Peer, Addr) ≝
CASE Peer.PodSelector ≠ NIL Peer.NamespaceSelector ≠ Nil
→ ∃ S ∈ Pods:
∧ S.Labels match From.PodSelector
∧ S.NameSpace match From.NamespaceSelector
∧ S.Status.PodIP = Addr
◻︎ Peer.PodSelector ≠ NIL Peer.NamespaceSelector = Nil
→ ∃ S ∈ Pods:
∧ S.Labels match From.PodSelector
∧ S.NameSpace = Pol.Namespace
∧ S.Status.PodIP = Addr
◻︎ Peer.PodSelector = NIL Peer.NamespaceSelector ≠ Nil
→ ∃ S ∈ Pods:
∧ S.NameSpace = From.NamespaceSelector
∧ S.Status.PodIP = Addr
◻︎ Peer.PodSelector = NIL Peer.NamespaceSelector = Nil
→ ∧ sAddr ∈ as-set(From.IPBlock.CIDR)
∧ ∄ Except in From.IPBlock.Except
Addr ∈ as-set(Except)
Please visit Kubernetes Networking for a discussion of the Kubernetes Networking Model and the Conceptual Networking Model used throughout this blog post:
In this model, a network is a Network Graph that consists of a set of Nodes and a set of Links between the Nodes: One Node may exchange a message with another Node if and only if there exists a link between the Nodes.
A Node in the network is either a Process or a Switch. Processes produce and consume messages, Switches process messages according to their Forward Information Base (FIB).
Kubernetes provides a Network Specification but Kubernetes does not provide a Network Implementation. In fact, many alternative implementations, called Network Plugins, exist today.
In order to use Kubernetes Network Policies, that is, in order for the presence of a Network Policy Object to have the desired effects, the installed Network Plugin must support Network Policies.
Figure 6. illustrates the example used in this section: A Kubernetes Cluster K₁ that consists of two Nodes. Each Node hosts two Pods. Each Pod resides in the default namespace and executes two Containers, one Container listening on port 8080, one Container listening on port 9090.
In addition
For this example, we will assume that following requirements:
In order to restrict communication we must flip
# Default Deny P₁’s Egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: frontend-policy
namespace: default
spec:
podSelector:
matchLabels:
role: frontend
policyTypes:
- Egress
# Default Deny P₂’s Ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-policy
namespace: default
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Ingress
The frontend-policy and backend-policy result in a network configuration that is equivalent to
In order to allow communication from P₁ to P₂ we must flip
# Explicitly Allow P₁’s Egress to P₂
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: frontend-policy
namespace: default
spec:
podSelector:
matchLabels:
role: frontend
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
role: backend
# Explicitly Allow P₂’s Ingress from P₁
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-policy
namespace: default
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
The frontend-policy and backend-policy result in a network configuration that is equivalent to
In conclusion, P₁ may receive messages from any source but may only send messages to P₂, while P₂ may only receive messages from P₁ but may send messages to any target.
In combination, P₁ may exchange messages with P₂.
The Kubernetes Networking Model guarantees that all Kubernetes Pods on a Kubernetes Cluster are able to communicate, that is, able to exchange messages. However, the Networking Semantics change in the presence of Networking Policies from Default Allow for all Pods to Default Deny for selected Pods with Explicit Allow.
In a nutshell, for two Pods to communicate