Category: Kubernetes Security

bookmark_borderNetwork Policies in Kubernetes

Posted on by Jay Jo

Ingress and Egress

Ingress and Egress
  1. In a Frontend Server (80/433), the incoming traffic on 80 or 433 from the users is ingress traffic. The outgoing request to the Backend server is egress traffic.
  2. In a Backend Server (3000), the incoming traffic on 3000 from the Frontend is ingress traffic. The outgoing request DataBase is egress traffic.
  3. In a DataBase (3306), the incoming traffic on 3306 from the Backend Server is ingress traffic. The outgoing request Backend Server is egress traffic.

When you define ingress and egress, you should look at the direction in which the traffic originated.

Network Security

We have a cluster with a set of nodes hosting a set of pods and services. Each node has an IP address and so does each pod as well as service. One of the pre-requisite for networking in Kubernetes, is whatever solution you implement, the pods should be able to communicate with each other without having to configure any additional settings like routes.

In the network solution, all pods are on a virtual private network that spans across the nodes in the Kubernetes cluster, and they can all by default reach each other using the IPs or Pod names ore services configured for that purpose. Kubernetes is configured by default with All Allow rule that allows traffic from any pod to any other pod or services within the cluster.

In the Kubernetes

for each component in the application we deploy as a pod. one frontend, one backend, and one database. Also, we create services to enable communication between the pods as well as to the end user. By default all the pods can communicate with each other within Kubernetes cluster.

What if we do not want the frontend to be able to communicate with the database server directly. Your security teams and audits require you to prevent that from happening. That is where you would implement a Network Policy to allow traffic to the DataBase only from Backend server.

A Network Policy is another object in the Kubernetes namespace. Just like Pods, ReplicaSets, or Services. You can like a network policy to one or more pods.

Case 1 All ingress traffic from Backend pod on port 3306.

Once the policy is created, it blocks all other traffic to the pods and only allows traffic that matches the specified rule.

How do you apply or link a network policy to a pod?

Labels and Selectors.

We label the pod and use the same labels on the pod selector field in the network policy.

https://kubernetes.io/docs/concepts/services-networking/network-policies/

Example)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 3306
kubectl create -f db-policy.yaml 
networkpolicy.networking.k8s.io/db-policy created

Solutions that support Network Policies

  • Kube-router
  • Calico
  • Romana
  • Weave-net

Solutions that do not support Network Policies

  • Flannel
ANOTE.DEV