Best Practices for Kubernetes Network Policies

By Reuven Harrison

For starters:

Remember to enable a CNI that supports network policies when deploying the cluster!

A good policy should restrict ingress access:

1. The default Kubernetes policy is “any-any-any allow” so every namespace should have a deny all policy to correct this insecure default
2. No service should allow incoming traffic from external IPs unless it has a load-balancer or ingress attached to it
3. Services with a load-balancer or ingress should only allow access from the load-balancer IPs:
   - GKE: 130.211.0.0/22 and 35.191.0.0/16
   - EKS: 143.231.0.0/16
   - AKS: ?
4. Services should only accept traffic on the protocol/port that is served by its pods. For example, a web service should only access incoming traffic on HTTP (and never on its admin port!).
5. Services should only accept traffic from other services (pods) that consume them, either in the same namespace or from another namespace.
   In order to write an ingress policy from a pod in another namespace, you need add a label to the namespace.
6. The Kubernetes DNS service should only allow ingress access on UDP 53 from other pods (not from external IPs).

A good policy should restrict egress to a minimum:

Egress policies are more difficult to configure than ingress for several reasons:

1. People often don’t know which external services their pods need to consume (typically cloud services like storage, key management, message queues etc.)
2. Consuming services outside of the cluster is often based on a DNS name which isn’t supported by Kubernetes network policies (only IP addresses).
3. When enforcing egress policies, you must be careful not to block connectivity to essential services like the Kubernetes DNS service

You should prohibit outbound traffic from pods that don’t need to connect externally. This can help prevent data exfiltration and downloading of malicious binaries.

Start by detecting the external services your service consumes. You can easily do this with Tufin SecureCloud.

SecureCloud Service Graph

If there are no external dependencies, apply a block egress policy. But remember to allow connectivity to the Kubernetes DNS service.

If your service depends on external services, make sure you understand what they are and whether they are really needed and then apply policies to allow the connections.

If your pod needs to connect to a DNS (FQDN) name that doesn’t have a fixed IP address, you cannot do it with Kubernetes policies. Instead, you‘ll need to allow egress access to any IP address (excluding your pod subnet) and then to use an external firewall or proxy to restrict access to the DNS name.

For more details about network policies, see my blog post.