You are currently viewing Kubernetes Network Policy: Everything You Need to Know

Kubernetes Network Policy: Everything You Need to Know

As you know, Kubernetes is an open source platform to manage containerized workloads and services. Being a rapidly growing ecosystem Kubernetes services, support, and tools are available globally. 

Kubernetes allows you to easily run multiple apps inside one cluster. Due to the lack of network isolation by default in Kubernetes all apps are free to communicate with each other. Kubernetes Network Policies address this issue.  

In this article, we’ll provide a comprehensive guide about What Kubernetes policy is, Why it  is important, How to use Kubernetes Network Policies and everything you need to know. 

Let’s get started.

What is Kubernetes Network policy?

If you wish to control traffic flow at the IP address or port level for TCP, UDP, and SCTP protocols, Kubernetes Network Policy might be considered in Kubernetes clusters. Network policy is an application-centric management tool that allows you to define which of your specific Pod is allowed to communicate with various network entities. 

Each Network Policy targets a group of Pods and defines the network endpoints they can communicate with for both Ingress (incoming traffic) and Egress (outgoing traffic).

There are three different ways to identify target endpoints:

  1. Specific Pods: Pods matching a label are allowed
  2. Specific Namespaces: All Pods in the namespace are allowed
  3. IP address blocks: Endpoints with an IP address in the block are allowed

Why is Kubernetes Network Policy Required?

Kubernetes network policy is an essential tool to manage and secure applications in the Kubernetes cluster. Here are some important capabilities that tell us why we should use network policies-

  1. Kubernetes Network policies provide an additional layer of security by preventing unauthorized access. They enforce organizational or regulatory compliance requirements.
  2. Network policies allow segmentation of your application and controlling the flow of network traffic between different parts of the cluster.
  3. Network policies can be used to traffic optimization, resource utilization and minimize network congestion.

How does Kubernetes Network Policy Work?

Here we will go through how Kubernetes policies are implemented and how they work. There are endless conditions where you will need to allow or deny traffic from a specific source. Kubernetes Network policies work by allowing you to define some rules or protocols that define how pods should communicate with each other and other endpoints in a network cluster. 

They are implemented using a Container Network Interface (CNI) plugin that is installed in the cluster. These are defined as Kubernetes objects through a YAML file that includes the desired selectors, Ingress and Egress rules. These policies are applied using the Kubernetes API and can be created and updated using command-line tools or the Kubernetes Dashboard.Rules of Kubernetes Policies include- 

  • Traffic is allowed unless there is a policy selecting a pod.
  • Traffic is denied if policies are selecting the pod but none of them have any rules allowing it.
  • Traffic is allowed if there is at least one policy that allows it.

What Are Use Cases Of Kubernetes Network Policy?

Here are some use cases of how they allow and prevent desired Pod network access such as in the following scenarios:

  • Databases running in Kubernetes are often accessed by other in-cluster Pods, such as the Pods that run your app’s backend. Network Policies enable you to enforce this restriction, preventing other applications from communicating with your database server.
  • Sometimes Pods need not to accept any incoming traffic from other Pods in your cluster. Network Policy can block all Ingress traffic to them and tighten your workload’s security.
  • Kubernetes namespaces keep objects separate associated with different apps, teams, and environments. By using Network Policies, you can isolate these resources and achieve stronger multi-tenancy.

How to create a Network Policy in Kubernetes?

Prerequisites

  • A Kubernetes cluster with Network Policy support. 
  • The network-policy admission controller should be enabled.
  • Familiarity with Kubernetes pods, services, and namespaces.
  • Network Plugin that supports Network policies.eg. Calico, Cilium etc.

Creating Kubernetes Network Policy 

  1. First you need to create a YAML file. You can name it something like network-policy.yaml.
  1. Define the Network Policy in YAML file by specifying the API version, kind, metadata, and the spec section which includes the policy types, pod selectors, and Ingress/Egress rules.

Here is an example of a basic Network Policy YAML file:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-Ingress-from-specific-namespace
namespace: default
spec:
podSelector:
matchLabels:
app: myapp
policyTypes:
- Ingress
- Egress
Ingress:
- from:
- namespaceSelector:
matchLabels:
project: myproject
ports:
- protocol: TCP
port: 80
Egress:
- to:
- namespaceSelector:
matchLabels:
project: myproject
ports:
- protocol: TCP
port: 80

3. Now Apply the Network Policy using the kubectl command to create the Network Policy in your cluster.

kubectl apply -f network-policy.yaml

Important Terms and Concepts: Kubernetes Network policy

  • Default deny: Default deny means all traffic is denied by default.
  • Default allow: Default allow means all traffic is allowed by default.
  • apiVersion : version of the Kubernetes API.
  • kind is set to NetworkPolicy
  • metadata section includes the name of the Network Policy and the namespace it applies to.
  • The spec section defines the policy.
  • podSelector specifies the pods the policy applies to (in this case, pods labeled app: myapp).
  • policyTypes indicates whether the policy applies to Ingress, Egress, or both.
  • Ingress defines the allowed incoming traffic (from pods in namespaces labeled project: myproject on port 80).
  • Egress defines the allowed outgoing traffic (to pods in namespaces labeled project: myproject on port 80).

Examples of Kubernetes Network Policies

When no policy is defined, The default Kubernetes policy permits pods to control traffic. Every Pod can communicate with one another freely.

1. Default Deny all Ingress Traffic

    You can deny Ingress traffic for a namespace by creating a Network Policy that selects all pods but does not allow any Ingress traffic to those pods.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
    name: default-deny-Ingress
    spec:
    podSelector: {}
    policyTypes:
    - Ingress

    2. Default Allow all Ingress Traffic

    If you want to allow all incoming traffic to all pods in a namespace. You can create a policy that allows all Ingress traffic in that namespace.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
    name: allow-all-Ingress
    spec:
    podSelector: {}
    Ingress:
    - {}
    policyTypes:
    - Ingress

    3. Default Deny all Egress Traffic

    You can deny all outgoing or Egress traffic for a namespace by creating a Network Policy that selects all pods but does not allow any Egress traffic from those pods.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
    name: default-deny-Egress
    spec:
    podSelector: {}
    policyTypes:
    - Egress

    4. Default Allow all Egress Traffic

    If you want to allow all outgoing or Egress traffic from all pods in a namespace. You can create a policy that permits all Egress traffic.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
    name: allow-all-Egress
    spec:
    podSelector: {}
    Egress:
    - {}
    policyTypes:
    - Egress

    5. Default deny all Ingress and all Egress traffic

    You also can create a “default” policy for a namespace that does not allow all Ingress and Egress traffic in that namespace.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
    name: default-deny-all
    spec:
    podSelector: {}
    policyTypes:
    - Ingress
    - Egress

    Best Practices for Kubernetes Network Policy

    Here are some best practices for using Kubernetes Network Policy:

    • Always start by deny-all Ingress traffic policy and gradually allow only the necessary traffic as you find it secure.
    • Use labels to define policies for pods and services which makes it easier to manage and maintain policies as your cluster evolves over time.
    • Use namespace-level policies to block network traffic between namespaces, preventing pods in one namespace from accessing pods in another namespace.
    • Use explicit allow rules for traffic that need to be allowed instead of relying on an implicit allow-all rule.
    • Use network segmentation method to divide the network into parts, limiting the flow of traffic between segments. This helps to avoid data breach.
    • Regularly review and update policies to ensure that they are still relevant and effective in preventing security breaches.

    By following these above best practices, you can effectively use Kubernetes Network Policy to improve the security of your cluster. It helps to reduce the risk of a security breach.

    Choose Supportfly For Kubernetes Consulting Services

    Creating and maintaining Kubernetes Network Policies might be a daunting and time consuming task for you. But dont worry and leave it to us. Get professional Kubernetes consulting services with SupportFly. We offer a wide range of Kubernetes related services, starting from assessment and planning to cluster design, application containerization, security implementation, monitoring, and CI/CD integration. We cover all aspects of Kubernetes implementation and optimization.

    Conclusion

    In this guide, we’ve explained Kubernetes Network Policies in depth with all the aspects you need to know. Pods have no network isolation by default, so it’s crucial to set up an appropriate Network Policy for each of your applications. This helps to secure your Kubernetes cluster and its workloads against compromised containers that try to make malicious network communication. Still if you have any queries about it. Feel free to reach us.