How To Think About Securing Kubernetes With WAF And DoS protection

To best protect cloud-native apps, you need to deploy flexible, Kubernetes‑friendly WAF and DoS protections at the right places in your infrastructure.

For any team deploying applications, web application firewalls (WAFs) and denial-of-service (DoS) protection are table stakes. That said, Kubernetes does make it more complicated to deploy these crucial tools in the right way. In Kubernetes, east-west traffic needs to be protected just as carefully as north-south traffic even though the elements of the underlying infrastructure are more ephemeral than in traditional application deployments.

With this in mind, choosing the right WAF and DoS protection for Kubernetes apps depends on two factors in addition to features:

• Flexibility – There are scenarios when it’s best to deploy tools inside Kubernetes, so you want infrastructure‑agnostic tools that can run within or outside Kubernetes. Using the same tool for all your deployments enables you to reuse policies and lowers the learning curve for your SecOps teams.
• Footprint – The best Kubernetes tools have a small footprint, which allows for appropriate resource consumption with minimal impact to throughput, requests per second, and latency. Given that DevOps teams often resist security tools because of a perception that they slow down apps, choosing a high‑performance tool with a small footprint can increase the probability of adoption.

While a tool that consolidates WAF and DoS protection may seem more efficient, it’s actually likely to have issues around both CPU usage (due to a larger footprint) and flexibility. You’re forced to deploy the WAF and DoS protection together, even when you don’t need both. Ultimately, both issues can drive up the total cost of ownership for your Kubernetes deployments while creating budget challenges for other essential tools and services.

Once you’ve chosen the right security tools for your organization, it’s time to decide where to deploy those tools. There are four locations where application services can typically be deployed to protect Kubernetes apps:

• At the front door (on an external load balancer) – Good for “coarse‑grained” global protection because it allows you to apply global policies across multiple clusters
• At the edge (on an Ingress controller) – Ideal for providing “fine‑grained” protection that’s standard across a single cluster
• At the service (on a lightweight load balancer) – Can be a necessary approach when there are a small number of services within a cluster that have a shared need for unique policies
• At the pod (as part of the application) – A very custom approach that might be used when the policy is specific to the app

So, out of the four options, which is best? Well…that depends!

Where to Deploy a WAF

First, we’ll look at WAF deployment options since that tends to be a more nuanced choice.

• Front door and edge – If your organization prefers a defense-in-depth security strategy, we recommend deploying a WAF at both the external load balancer and the Ingress controller to deliver an efficient balance of global and custom protections. security strategy, we recommend deploying a WAF at both the external load balancer and the Ingress controller to deliver an efficient balance of global and custom protections.
• Front door or edge – In the absence of a defense-in-depth strategy, a single location is acceptable and the deployment location depends on ownership. When a traditional NetOps team owns security, they may be more comfortable managing it on a traditional proxy (the external load balancer). However, DevSecOps teams that are comfortable with Kubernetes (and prefer having their security configuration in the vicinity of their cluster configs) may choose to deploy a WAF at the Ingress level.
• Per service or pod – If your teams have specific requirements for their services or apps, then they can deploy additional WAFs in an à la carte fashion. But be aware: these locations come with higher costs. In addition to increased development time and a higher cloud budget, this choice can also increase operational costs related to troubleshooting efforts – such as when determining “which of our WAFs is unintentionally blocking traffic?”

Where to Deploy DoS Protection

Protection against DoS attacks is more straightforward since it’s only needed at one location – either at the front door or at the Ingress controller. If you deploy a WAF both at the front door and the edge, then we recommend that you deploy DoS protection in front of the front‑door WAF, as it’s the most global. In this way unwanted traffic can be thinned out before hitting the WAF, allowing you to make more efficient use of compute resources. That said, you may also want to deploy DoS in a more distributed manner – using CDNs or using several layers of DoS protection in public cloud implementations.

Conclusion: Cloud-Native Rules for Kubernetes Security

Cloud-native computing has redefined the way we deploy and operate applications and infrastructure. Loosely coupled Kubernetes-based deployments of services and applications require a new approach of flexibility and defense-in-depth that matches the new infrastructure footprint. Gone are the days of slapping a WAF in front of an application and calling it a day. Likewise, with most applications utilizing layers of internal and external services for different capabilities, Kubernetes security architects need to think about the footprint of their functional infrastructure and map security locations appropriately to cover their cloud-native needs. By thinking about Kubernetes security in this light, organizations can deploy even the most sensitive applications in a cloud-native way with confidence that their apps are safe from attacks.

Guest post originally published by Jenn Gile of NGINX
Source CNCF