Logo

Kubernetes Network Policies for Pods and Namespaces Isolation

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/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  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/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: backend
spec:
  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/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
policyTypes:
  - 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?

We will give a training about pentesting and securing docker swarm & kubernetes environments at Black Hat USA, HITB, Ekoparty and SIGS! Get your ticket!

 

___________

References

Sheila A. Berta
Head of Research at Dreamlab Technologies

Kubernetes Network Policies for Pods and Namespaces Isolation

Todas las entradas