Denial of Service

Denial of Service (DoS) is about making something unavailable.

There are many types of DoS attacks, but a well-known variation is overloading a system to the point it can no longer service requests. In the Kubernetes world, a potential attack might be overloading the API server so that cluster operations grind to a halt (even internal systems use the API server to communicate).

Let’s look at some potential Kubernetes systems that might be targets of DoS attacks, as well as some ways to protect and mitigate them.

Protecting cluster resources against DoS attacks

It’s a time-honored best practice to replicate essential services on multiple nodes for high availability (HA). Kubernetes is no different, and we should run multiple control plane nodes in an HA configuration for our production environments. Doing this prevents any control plane node from becoming a single point of failure. In relation to certain types of DoS attacks, an attacker may need to attack more than one control plane node to have a meaningful impact.

We should also replicate control plane nodes across availability zones. This may prevent a DoS attack on the network of a particular availability zone from taking down our entire control plane.

The same principle applies to worker nodes. Having multiple worker nodes not only allows the scheduler to spread our applications over multiple availability zones, but it may also render DoS attacks on any single node or zone ineffective (or less effective).

We should also configure appropriate limits for the following:

• Memory

• CPU

• Storage

Limits like these can help prevent essential system resources from being starved, therefore preventing potential DoS.

Limiting Kubernetes objects can also be a good practice. This includes limiting things such as the number of ReplicaSets, Pods, Services, Secrets, and ConfigMaps in a particular Namespace.

Here’s an example manifest that limits the number of Pod objects in the skippy Namespace to 100.