This tutorial will teach you how to create a network policy using the Editor. It explains basic network policy concepts and guides you through the steps needed to achieve the desired least-privilege security and zero-trust concepts.

First, select the pods to which the policy should be applied by matching pod labels. A network policy can be applied to an individual pod, a group of pods, an entire namespace, or an entire cluster.¹ If the pod selector is left empty, the policy will be applied to all the pods in a namespace.

¹ Clusterwide Policies are not yet implemented in the Editor.

The standard network security posture of Kubernetes allows all network traffic. You are responsible for restricting all communication by introducing a “default deny” posture and then allowing only the desired network communication. This can be done incrementally — that is, you can place individual pods, groups of pods, or entire namespaces into a default deny posture. Or you can tackle ingress (traffic into the pod) and egress (traffic out of a pod) communication separately.

An empty policy with only a pod selector does not enforce any rules. By adding a rule (even an empty rule), the selected pods will change into a default deny posture for the selected traffic direction. Decide if you want to set ingress, egress, or both to a default deny posture by adding an empty rule.

For this tutorial, enable default deny for both ingress and egress.

The pods will likely want to resolve DNS queries on port 53/UDP. Allow communication to Kubernetes DNS. Specifically, you should explicitly allow egress traffic to port 53/UDP only to kube-dns pods in the cluster, rather than allowing it to any endpoint on the Internet.

Advanced: When using Cilium Network Policies, you can enable DNS-proxy to observe and filter all DNS egress traffic for the selected pods.

Decide if the pods chosen by the pod selector will communicate with other pods in the same namespace.

Note: To allow traffic between two pods, the egress side of the sending pod and the ingress side of the receiving pod must both allow traffic. This ensures compliance with zero-trust principles by allowing each pod to enforce its own policy instead of relying on the policies of other pods.

All traffic from outside the cluster is currently dropped. Decide if the isolated pods should receive ingress traffic from outside the cluster.

All traffic to endpoints outside of the cluster is currently dropped. You can allow egress traffic to the entire Internet; however, we recommend allowing traffic only to known DNS names, known CIDRs, or a specific port, like port 80 or 443, at the least.

Think about cross-namespace communications. Even if you allowed all ingress or egress from/to the entire Internet, the rules would not match the ingress or egress traffic coming from pods in other namespaces. If isolated pods might receive (ingress) or send (egress) traffic to pods in other namespaces, consider adding rules accordingly.

If your pod uses network-based liveness or readiness probes, then these probes happen via the network. Kubernetes requires that all NetworkPolicy implementations automatically allow traffic from the host to the pod.

Advanced: Automatically allowing traffic from the host to the pod is not ideal based on the principles of least-privilege and zero-trust. Click here for more information on configuring Cilium so that traffic to the host relies instead on explicit policy to define the security posture.

Congratulations! If you followed the tutorial, you now have a policy that you can enforce. To use network policies in Kubernetes, you must use a networking plugin that implements network policy specification; without it, the network policy will have no effect. One possible solution is Cilium. Continue by clicking the Download button and following the instructions.

Another hands-on way to learn about Cilium network policies by using the interactive labs from Isovalent.