What is K8s Network Policies

Kubernetes network policy lets administrators and developers enforce which network traffic is allowed using rules.
Network policy lets developers secure access to and from their applications using the same simple language they use to deploy them. Developers can focus on their applications without understanding low-level networking concepts. Enabling developers to easily secure their applications using network policies supports a shift left DevOps environment

Features

The Kubernetes Network Policy API supports the following features:

• Policies are namespace scoped
• Policies are applied to pods using label selectors
• Policy rules can specify the traffic that is allowed to/from pods, namespaces, or CIDRs
• Policy rules can specify protocols (TCP, UDP, SCTP), named ports or port numbers

First Step

Remember to enable a CNI that supports network policies when deploying the cluster!
Kubernetes has no built-in capability to enforce the network policy. To enforce network policy, you must use a network plugin such as Calico.

Ingress access best practices:

Ingress is incoming traffic to the pod.

1. The default Kubernetes policy is “any-any-any allow” , thi means each pod can reach every pod on every namespace , so every namespace 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:
   1. – GCP – GKE: 130.211.0.0/22 and 35.191.0.0/16
   2. – AWS – EKS: 143.231.0.0/16
4. Services should only accept traffic on the protocol/port that is served by its pods. For example, a web app should only access incoming traffic on HTTP/HTTPS.
5. Kubernetes DNS service should only allow inbound access on UDP 53, from ineternal services/pods.

Egress restrict best practices:

Egress is outgoing traffic from the pod , and it is more difficult to configure than ingress for several reasons:

1. Developers often don’t know which external services their applications need to consume (typically cloud services like databases, storage, 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 deny outbound traffic from pods that don’t need to connect externally. This can help prevent data exfiltration and downloading of malicious binaries.