Kubernetes Network Policies

Kubernetes Network Policies are rules that control how Pods communicate with each other and with external endpoints. By default, in Kubernetes, all Pods can talk to each other freely. Network Policies let you restrict or allow this traffic based on conditions such as namespace, labels, IP ranges, and ports.

Components of a Network Policy

1. Pod Selector – Defines which Pods the policy applies to (using labels).
2. Ingress rules – Define what incoming traffic is allowed.
3. Egress rules – Define what outgoing traffic is allowed.
4. Policy types – Can be Ingress, Egress, or both.

Creating a Kubernetes Network Policy

The mandatory fields for a NetworkPolicy, like other Kubernetes configurations, include:

• apiVersion
• kind
• metadata

Additionally, each NetworkPolicy has a policyTypes field that indicates whether it covers egress or ingress (or both). Since egress rules will automatically apply to egress traffic, the policy will apply to ingress traffic to the selected pods if this field is left blank. The default setting is Ingress.

• Ingress rules: These specify the types of ingress traffic that the Kubernetes NetworkPolicy permits. Rules are applicable to traffic from elements matching the designated ports.
• Egress rules: These define the permitted traffic in terms of ports and to elements.

Let’s look at a sample NetworkPolicy resource and then understand all the fields in a bit more detail.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: example-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 128.12.0.0/24
except:
- 128.12.46.0/16
- namespaceSelector:
matchLabels:
project: exampleproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- protocol: TCP
port: 5978

You must run the following command in order to implement the above policy:

kubectl apply -f network.yaml

Where network.yaml contains the above YAML code. The output looks like this:

👁 Kubectl Network

It is specified by this NetworkPolicy that pods that have the db role should be isolated. It defines ingress rules that permit traffic to all pods with the label "db" through port 6379 (as per the TCP protocol). Traffic from the following sources is included in this:

• Pods with frontend role.
• Pods with project label exampleproject.
• IP addresses within the specified ranges: from 128.12.0.0 to 128.12.255.255 except for the range between 128.12.46.0 to 128.12.46.255.

Additionally, the sample NetworkPolicy has egress rules that permit traffic to ports 5978 and addresses in the CIDR range 10.0.0.0/8 from any pod in the default namespace named db.

Understanding Kubernetes Network Policy Selectors

There are four kinds of selectors that can be specified in an ingress section or egress section. We’ll discuss them in this section:

PodSelector

This allows you to choose which specific pods in the same namespace as the NetworkPolicy should be permitted to enter as egress or ingress points.

👁 Screenshot-2024-02-14-154055

NamespaceSelector

This picks specific namespaces that all Pods are permitted to use as egress or ingress points.

👁 Screenshot-2024-02-14-154246

Combining Selectors

A single to/from entry that specifies both 'namespaceSelector' and 'podSelector' selects particular Pods within particular namespaces. Be careful to use correct YAML syntax. For example:

👁 Screenshot-2024-02-14-154651

A single from element in this policy permits connections from Pods in namespaces labeled user=client with the label role=server. However, the subsequent policy is distinct:

👁 Screenshot-2024-02-14-154937

It accepts connections from any Pod in any namespace with the label user=client, or from any Pod in the local namespace with the label role=server. It has two elements in the from array.

IpBlock

To permit communication to or from particular IP address CIDR ranges, ipBlock selectors are employed. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.

Rewriting the packet's source or destination IP is frequently necessary for cluster ingress and egress procedures. When this occurs, it's unclear if it occurs before to or following NetworkPolicy processing, and the behavior can vary depending on the network plugin, cloud provider, service implementation, and other factors that are combined.

👁 Screenshot-2024-02-14-155656

Kubernetes Default Network Policy examples

Default Network Policies in Kubernetes help control the traffic flow between pods by defining a set of rules that specify how pods are allowed to communicate with each other.

Unless specifically overridden by another Network Policy, Default Network Policies are applicable to all pods, in contrast to normal Network Policies that explicitly permit or prohibit traffic.

The following examples let you change the default behavior in that namespace.

Deny all ingress traffic

To build a "default" ingress isolation policy for a namespace, construct a NetworkPolicy that chooses all pods but does not allow ingress traffic to those pods.

👁 Screenshot-2024-02-14-160643

Deny all egress traffic

You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods.

👁 Screenshot-2024-02-14-160951

Allow all ingress traffic

With this policy in effect, no further policies can deny any inbound connections to those pods. This policy has no effect on isolation during egress from any pod.

👁 Screenshot-2024-02-14-161221

Allow all egress traffic

If you want to allow all connections from all pods in a namespace, you can create a policy that explicitly allows all outgoing connections from pods in that namespace.

👁 Screenshot-2024-02-14-161347

Deny all ingress and all egress traffic

By setting the following NetworkPolicy in a namespace, you may set up a "default" policy that blocks all incoming and outgoing traffic.

👁 Screenshot-2024-02-14-161627

Kubernetes Network Policy Use Cases

One recommended practice for a secure Kubernetes configuration is to use Network Policies. They stop Pod network access from being overly widespread in situations like these:

• Permit particular applications or namespaces to talk to one another: The main method for segregating objects connected to various apps, teams, and environments is to use Kubernetes namespaces. To strengthen multi-tenancy and network-isolate these resources, you can employ Network Policies.
• Making sure an app's database can only be accessed by that app Kubernetes databases are frequently designed so that other in-cluster pods, like the ones that manage the backend of your app, are the only ones that can access them. You can enforce this restriction by using network policies, which will stop other applications from interacting with your database server.
• Implement a deny-all policy first: Begin by blocking all network traffic, then progressively permit only the traffic that is identified as necessary. By doing this, the attack surface is decreased and the chance of a security breach is decreased.
• Employ network segmentation: Utilize network segmentation to split the network into more manageable sections and restrict traffic flow between them. By doing this, the attack surface is decreased and the chance of a data breach is decreased.
• Isolating Pods from your cluster’s network: Some sensitive Pods might not need to accept any inbound traffic from other Pods in your cluster. Using a Network Policy to block all Ingress traffic to them will tighten your workload’s security.

You may effectively use Kubernetes Network Policy to enhance your Kubernetes cluster's security and lower the likelihood of a security breach by adhering to these best practices.