kubernetes Network Policlies

Everyone agrees that Kubernetes clusters are insecure by default. But the good news is that Kubernetes provides the tools to make that happen. In this article, we’re going to learn about one of the resources that K8s provides straight out of the box to help make your deployed apps more secure: Network policies.

A Kubernetes network policy specifies how pods can communicate with one another and other network endpoints in a Kubernetes cluster. Network policies provide fine-grained control over network traffic, allowing you to partition your network and secure your applications. They allow you to set incoming and outgoing traffic rules for pods and are implemented in the Kubernetes cluster using a CNI plugin like Calico or Weave Net.

What are Kubernetes Network policies?

Kubernetes network policies are a crucial tool for managing and securing applications deployed in a Kubernetes cluster. Network Policies are a tool for managing network traffic in Kubernetes clusters. They allow you to specify which of your Kubernetes Pods can share network traffic. You should utilize them in your clusters to prohibit apps from communicating over the network, thereby limiting the harm if one of your apps is compromised.

Each Network Policy you create targets a group of Pods and sets the Ingress (incoming) and Egress (outgoing) network endpoints those Pods can communicate with.

There are three different ways to identify target endpoints:

• Specific Pods (Pods matching a label are allowed)
• Specific Namespaces (all Pods in the namespace are allowed)
• IP address blocks (endpoints with an IP address in the block are allowed)

How does Network Policy work?

Kubernetes network policies allow you to control the network traffic between pods in a cluster, providing an additional layer of security. It’s also possible to use Network Policies to block all network communications for a Pod or restrict traffic to a specific port range. Network Policies are additive, so you can have multiple policies targeting a particular Pod. They are implemented using a Container Network Interface (CNI) plugin that is installed in the cluster.

Using a YAML manifest file that contains the desired selectors, ingress, and egress rules, the network policies are defined as Kubernetes objects. To apply network policies, use the Kubernetes API. The Kubernetes Dashboard or command-line tools can be used to construct and edit them.

Defining a Network Policy

To specify which pods are covered by the policy, you can use a variety of selectors, including namespace selectors, CIDR blocks, and pod selectors. You can use these criteria to make the policy only target particular pods, namespaces, or network regions.

Basic network isolation is provided via the Kubernetes plugin, which is a default feature of Kubernetes and appropriate for basic use cases. More sophisticated network plugins, however, may offer further capabilities like network policies, which let you create and implement network security guidelines.

It is crucial to remember that network policies are additive, which means that they are applied to a group of pods in combination rather than one after the other. This means that the final set of rules for a set of pods is formed by combining the policies that apply to the same set of kubernetes pods. The policies won’t be enforced if they contradict how they apply to linked pods. For instance, two services cannot connect to one another if their communication policies clash.

Creating a Kubernetes Network Policy

The data needed to specify the network policy for a particular namespace is contained in the NetworkPolicy specification. To choose which pod group the policy covers, the policy has the podSelector element; for example, the example below pertains to pods that have the db role. By default, the selector will select each pod in the namespace if it is empty.

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:

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.

NamespaceSelector

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

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:

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:

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.

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.

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.

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.

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.

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.

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.

Network Policy best practices

Of course, there are some best practices to keep in mind when creating network policies in Kubernetes. Let’s take a look at a few of the most important ones.

1. Scale Network Policies in Large Clusters: You can achieve scalability by using selective pod labeling and pod matching rules, avoiding over-restrictive policies and using efficient network policy implementations. Don’t forget to periodically review and optimize your network policies to ensure that they’re still necessary and effective.
2. Monitor Network Policy Activity: Monitoring and logging network policy activities is essential to detect and investigate security incidents, troubleshoot network issues and identify opportunities for optimization.
3. Log Network policies: You may inspect the logs and status information for your network policies using Kubernetes tools like kubectl logs and kubectl describe. For increased insight into network activity and policy visibility, you may also employ third-party monitoring and logging services.
4. Ensure isolation: The first step in ensuring proper isolation is to identify which pods should be allowed to communicate with each other and which should be isolated from each other. Then define rules to enforce these policies. Since Kubernetes network policies allow you to control network traffic between pods, it’s important to define them well to ensure proper isolation.
5. Use precise target selectors: Make sure that your Pod selectors, namespace selectors, and ipBlock ranges are as accurate as feasible to avoid future instances of them unintentionally picking new Pods. If you want to deploy other Pods to the namespace, for instance, and those Pods shouldn’t automatically communicate with the target of your Network Policy, then a namespace selector is improper.

Conclusion

Clearly, Kubernetes network policies are a powerful tool for securing and controlling network traffic between workloads in your cluster. They allow you to define and enforce network security policies at a granular level, ensuring proper isolation and reducing the risk of unauthorized access or data breaches.

You’ve also learned some best practices for implementing network policies, such as monitoring and logging policy activity and evaluating third-party network policy solutions.

Kubernetes Network Policies – FAQ’s

How does a network security policy safeguard a company’s network?

A well-crafted network security policy can help protect a company’s network. You can create the policy in-house or hire the expertise of a cyber security business with experience designing security policies.

How does Kubernetes control traffic?

In Kubernetes, that capability is implemented by network plugins and managed by network policies. Note that network policies are not a substitute for firewalls.

What is the purpose of Network Policy?

Network policies are sets of conditions, and settings that allow you to designate who is authorized to connect to the network and the circumstances under which they can or cannot connect.

Is Kubernetes Network policy stateful or stateless?

Network Policy is stateful and will allow an established connection to communicate both ways.

Is Network Policy a namespace?

Keep in mind that a Network Policy is applied to a particular Namespace and only selects pods in that particular kubernetes Namespace.