Immersion in Kubernetes Network Policies

Kubernetes is a powerful container orchestration platform that helps scale and manage applications in a cluster. However, one of the key aspects that often goes unnoticed when deploying applications in Kubernetes is network security. Network Policies are a tool that provides the ability to control network interactions between objects in a cluster. In this article, we will understand how Kubernetes Network Policies work and their main elements, as well as how they can help improve the security and isolation of applications.

What are Network Policies?

Network Policies are an abstraction that allows you to define rules for network interactions between objects in a Kubernetes cluster. With their help, you can specify which Pods can send or receive traffic, how they can interact with external resources, and with each other within the cluster.

By default, in Kubernetes, all Pods can freely interact with each other, which can pose a security threat, especially in large clusters with many microservices. Network Policies allow you to restrict this traffic and provide additional isolation.

Main components of Network Policies

1. Pod Selector. This element defines which Pods the policy rules will apply to. Labels are usually used to identify the target Pods.

2. Ingress Rules. Ingress traffic rules. They define what traffic is allowed to enter the Pods covered by the policy. For example, you can allow traffic only from certain Pods or from external IP addresses.

3. Egress Rules. Egress traffic rules. They define where the Pods can send traffic. For example, you can restrict access only to certain external services or IP addresses.

4. Namespace Selector. Defines from which namespaces data can be received or sent. This is useful for separating network interactions between Pods in different namespaces.

5. Policy Types. The policy type indicates whether it applies only to incoming traffic (Ingress), only to outgoing traffic (Egress), or both.

Example Network Policy

Let's consider a simple example of a Network Policy that restricts incoming traffic to Pods with the label app: backend and allows it only from Pods with the label app: frontend.

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

Example Analysis

1. podSelector: we specify that this policy applies to Pods with the label app: backend.

2. policyTypes: the policy applies only to incoming traffic (Ingress).

3. ingress: here is a rule that allows incoming traffic only from Pods with the label app: frontend.

Thus, with this policy, we prevent all other Pods and external sources from interacting with our backend Pods, except those that have the label app: frontend.

Policies for Outgoing Traffic (Egress)

You can also set a policy for outgoing traffic. For example, restrict Pods' access only to a specific external service by IP address.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.0/24
  - ports:
    - protocol: TCP
      port: 80

Example Analysis

1. egress: it is defined that Pods with the label app: backend can send traffic only to the subnet 192.168.1.0/24 on TCP port 80.

2. policyTypes: the policy applies to outgoing traffic (Egress).

This policy restricts the ability of backend Pods to access the network and interact with external services outside the specified subnet.

Useful scenarios for using Network Policies

1. Service isolation. For example, you can isolate databases so that they are only accessible to certain services and prevent direct access from other Pods.

2. Restricting external access. You can restrict access to your application from the outside world, opening it only to certain sources or IP addresses.

3. Traffic segmentation. You can segment network traffic within a single namespace or between multiple namespaces, providing additional security for microservices.

4. Control of outgoing traffic. For example, you can control which external services Pods can connect to and prevent data from being sent to unwanted or potentially dangerous external resources.

Features and limitations

• Network Plugin. Network Policies only work with network plugins that support this functionality, such as Calico, Cilium, or Weave Net. This should be considered when choosing a network solution for your cluster.

• Complete blocking. If no policy is applied to the Pods, they can interact with other Pods freely. But as soon as at least one policy is created, all traffic that does not match the rules is blocked.

• Combination of rules. Policies can be combined to define complex network configurations covering various security scenarios.

Conclusion

Network Policies are an important tool for ensuring security and managing traffic in a Kubernetes cluster. Using these policies allows backend developers to ensure service isolation, control access to data, and improve the overall security of the system. Implementing network interaction rules is especially critical in microservice architectures, where a large number of Pods and services can interact with each other.

It is recommended to use Network Policies from the very beginning of application design, as their absence can lead to unpredictable security-related consequences.

vAITI — DIY media for IT professionals. Share personal stories about solving various IT tasks and get rewarded.