A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. The Kubernetes NetworkPolicy object uses labels to select pods and define rules which specify the traffic allowed to the selected pods.
By default, pods are non-isolated; they accept traffic from any source. It is possible to isolate Pods by having a network policy that selects them. Once there is any policy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by the network policy.
These policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.
Default deny all Ingress and Egress traffic
It is possible to create a "default" policy for a namespace which prevents all ingress and egress traffic to/from pods by creating the following network policy:
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: default-deny-allspec: podSelector: {} policyTypes: - Ingress - Egress |
The podSelector with value “{}” means that it selects all Pods in the namespace, otherwise it should indicate specific labels. This is commonly used as a policy to deny everything by default, then it is possible to create other policies to allow the necessary traffic.
Isolate namespaces from each other
A possibly common case would be to allow communication between Pods of the same namespace and prevent traffic from outside it. That means, isolate namespaces from each other.
It is possible to do that by creating a network policy like the following one:
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-same-namespace namespace: backendspec: podSelector: {} ingress: - from: - namespaceSelector: matchLabels: name: backend egress: - to: - namespaceSelector: matchLabels: name: backend |
In this example, all Pods that belong to the "backend" namespace will be able to communicate with each other, but they will not be able to do it with Pods from other namespaces.
In the image above is observed that a backend Pod can communicate with other backend Pod but not with a frontend one.
Advanced rules
Network policies can be as complex as required. It is possible to filter the traffic by ports, protocols, network ranges, specific groups of Pods, etc.
An additional example:
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: test-network-policy namespace: defaultspec: podSelector: matchLabels: role: dbpolicyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 |
In the above example the NetworkPolicy:
- Isolates "role=db" pods in the "default" namespace for both ingress and egress traffic (if they were not already isolated).
- Egress rules allow connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978.
- Ingress rules allow connections to all pods in the “default” namespace with the label “role=db” on TCP port 6379 from:
- Any pod in the "default" namespace with the label "role=frontend".
- IP addresses in the ranges 172.17.0.0–172.17.0.255 and 172.17.2.0–172.17.255.255 (ie, all of 172.17.0.0/16 except 172.17.1.0/24).
It is extremely important to create all the necessary network policies for the Kubernetes cluster. Having the correct rules will greatly increase the security of the environment and will be of great help in preventing "pivots" across the Pods and Namespaces if any are compromised.
Do you want to learn more?
https://dreamlab.net/en/education/trainings-schedule/
___________
References
Sheila A. Berta
Head of Research at Dreamlab Technologies
