A Kubernetes network policy is a specification that defines how pods are allowed to communicate with each other and other network endpoints in a Kubernetes cluster. Network policies enable fine-grained control over network traffic, enabling network segmentation and security for your applications. They allow you to define inbound and outbound traffic rules for pods and are implemented using a CNI plugin, such as Calico or Weave Net, in the Kubernetes cluster.
This is part of a series of articles about Kubernetes networking.
In this article:
Kubernetes network policies are a crucial tool for managing and securing applications deployed in a Kubernetes cluster. Important capabilities include:
Kubernetes network policies allow you to control the network traffic between pods in a cluster, providing an additional layer of security. These policies work by allowing you to define rules that control how pods communicate with each other and other network endpoints in a cluster. They are implemented using a Container Network Interface (CNI) plugin that is installed in the cluster.
The network policies are defined as Kubernetes objects, via a YAML manifest file that includes desired selectors, ingress and egress rules. Network policies are applied using the Kubernetes API. They can be created and updated using command-line tools or through the Kubernetes Dashboard.
How to define a network policy
There are different types of selectors that you can use to define the pods that are subject to the policy, such as CIDR blocks, pod selectors, and namespace selectors. These selectors allow you to target specific pods, namespaces, or network ranges for the policy.
It is important to note that network policies are additive, meaning that multiple policies are applied to a set of pods, rather than sequentially. This means that if multiple policies apply to the same set of pods, the policies are combined to form the final set of rules for that set of pods. If there are conflicts in the policies applied to related pods, the policies will not be enforced. For example, if two services have conflicting communication policies, they cannot connect to each other.
By default, Kubernetes includes a simple network plugin called kubenet, which provides basic network isolation and is suitable for simple use cases. However, more advanced network plugins can provide additional features such as network policies, which allow you to define and enforce network security policies.
Learn more in our detailed guide to Kubernetes network security
This is based on an example shared in the Kubernetes documentation.
NetworkPolicy spec contains the information required to define the network policy for a specific namespace. The policy includes the
podSelector element to select the pod group that the policy covers—for instance, the below example applies to pods with the
db role. If the selector is empty, it will select every pod in the namespace by default.
The mandatory fields for a
NetworkPolicy, like other Kubernetes configurations, include:
Every NetworkPolicy also has a policyTypes field that specifies if it applies to
Egress (or both). The default is
Ingress, meaning that if this field is not specified, the policy will apply to ingress traffic to the selected pods, although egress rules will automatically apply to egress traffic:
Here is an example of a
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: 188.8.131.52/24 except: - 184.108.40.206/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
In order to execute the above policy you will need to run the following command:
kubectl apply -f network.yaml
network.yaml contains the above YAML code. The output looks like this:
NetworkPolicy specifies that pods with the
db role should be isolated. It specifies ingress rules to allow traffic to all pods labeled
db via port 6379 (according to the TCP protocol). This includes traffic from the following sources:
NetworkPolicy also includes egress rules that allow traffic from all pods within the default namespace labeled
db to the addresses within the CIDR range 10.0.0.0/8 and on port 5978.
Related content: Read our guide to Kubernetes security policies
Here are some best practices for using Kubernetes Network Policy:
By following these best practices, you can effectively use Kubernetes Network Policy to improve the security of your Kubernetes cluster and reduce the risk of a security breach.
Calico’s flexible modular architecture supports a wide range of deployment options, so you can select the best networking approach for your specific environment and needs. This includes the ability to run with a variety of CNI plugins and also leverage Calico’s IPAM capabilities and underlying network types, in non-overlay or overlay modes, with or without BGP.
Calico’s flexible modular architecture for networking includes the following:
In addition to providing both network and IPAM plugins, Calico also integrates with a number of other third-party CNI plugins and cloud provider integrations, including Amazon VPC CNI, Azure CNI, Azure cloud provider, Google cloud provider, host local IPAM, and Flannel.
Get updates on blog posts, workshops, certification programs, new releases, and more!