How to make a Network Policies in Kubernetes

In a Kubernetes cluster, network security is paramount, especially when it comes to ensuring that traffic flow is controlled and secure. Network Policies in Kubernetes provide a way to enforce rules about which pods can communicate with each other and with other network endpoints. This tutorial will help developers understand Network Policies, their rules, and practical examples of their usage.

Introduction to Network Policies

A Network Policy is a Kubernetes resource that defines how groups of pods are allowed to communicate with each other and other network endpoints. By default, Kubernetes allows all traffic to flow between pods in a cluster. However, in a production environment, it is crucial to restrict this communication to enhance security and limit potential attack vectors.

Notes!

By default, Kubernetes allows all traffic to flow between pods in a cluster. However, when you set a rule in the Network Policy, Kubernetes changes this default to a “deny-all” policy. In other words, any traffic that does not match the specified allow rules in the network policies will be blocked.

Network Policies are based on labels and selectors, making them flexible and powerful. They can define rules for both ingress (incoming) and egress (outgoing) traffic.

Network Policies consist of several key elements:

1. Pod Selector: Specifies which pods the policy applies to based on their labels.
2. Policy Types: Defines whether the policy is for ingress, egress, or both.
3. Ingress Rules: Specifies the allowed incoming traffic.
4. Egress Rules: Specifies the allowed outgoing traffic.

Example Structure of a Network Policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 6379

Types of Policy Rules

Ingress Rules

Ingress rules control which traffic is allowed to enter the pods specified by the podSelector.

Example: Allowing Traffic from Specific Pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

This policy allows traffic to pods labeled app: backend from pods labeled app: frontend.

Example: Allowing Traffic from Specific Namespaces:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-namespace-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchNames: 
        - my-namespace

This policy allows traffic to pods labeled app: my-app from any pod in namespaces named my-namespace.

Example: Allowing Traffic on Specific Ports:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-http-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

This policy allows HTTP (port 80) and HTTPS (port 443) traffic to pods labeled app: my-app.

Egress Rules

Egress rules control which traffic is allowed to leave the pods specified by the podSelector.

Example: Allowing Egress to Specific Pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 6379

This policy allows traffic from pods labeled app: frontend to pods labeled app: backend on port 6379.

Example: Allowing Egress to Specific IP Blocks:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-external-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24

This policy allows traffic from pods labeled app: my-app to IP addresses in the 10.0.0.0/24 range.

Example: Allowing Egress on Specific Ports:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Egress
  egress:
  - ports:
    - protocol: UDP
      port: 53

This policy allows DNS traffic (UDP on port 53) from pods labeled app: my-app.

Combining Ingress and Egress Rules

Network Policies can combine both ingress and egress rules to provide comprehensive traffic control.

Example: Combined Ingress and Egress Policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: combined-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: trusted-app
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 8080

This policy allows ingress traffic from pods labeled app: trusted-app and egress traffic to pods labeled app: backend on port 8080.

Conclusion

Network Policies in Kubernetes are a powerful tool to control traffic flow within your cluster, enhancing security and reducing the risk of malicious activity. By defining precise rules for ingress and egress traffic, you can ensure that only authorized communication occurs between pods and other network endpoints.

By understanding and implementing Network Policies, developers can create more secure and efficient Kubernetes environments. This guide provides a solid foundation, but always remember to tailor policies to your specific use case and continually refine them to adapt to changing requirements.