_Towards a modern approach for addressing security threats, mitigating risks, and shielding application deployments on Kubernetes with modern WAF architecture
_
A web application firewall (WAF) is a crucial part of network security architecture that inspects, sanitizes, and redacts malicious HTTP requests for applications. Since WAFs are operating on the application layer (layer 7 in the OSI model), traffic payloads originating from users and bots can be analyzed, in the hopes of blocking malicious clients and letting legitimate client requests proceed.
WAF architecture is a critical part of any enterprise platform as they’ll protect against Distributed Denial of Service (DDOS) attacks, OWASP Top Ten security risks, and apply advanced rate limiting strategies.
A WAF will typically be used to safeguard dynamic services and APIs alongside a content delivery network (CDN) that will cache and distribute static assets (images, videos, etc.) all the while protecting from DDOS attacks.
The Payment Card Industry Data Security Standard (PCI DSS), defines a web application firewall as:
a security policy enforcement point positioned between a web application and the client endpoint. This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system. It may be a stand-alone device or integrated into other network components.
From that definition alone, we can see how web application firewalls can take many different forms in enterprise solutions: from on-premise data center appliances to software solutions deployed in multiple configurations. Let us explore our options to protect the edge of our network with Kubernetes and cloud native applications in mind.
On-premise Data Center Appliances
Not long ago, we lived in an era where on-premise data centers were the norm. Server racks were hand-crafted and managed by infrastructure, operations, system administrators and infosec teams. Proxies, load-balancers and WAFs were physical appliances installed in cabinets. It was, and quite frankly still is, an option for many enterprises for whom using the public cloud is not an option. In this WAF architecture, the Firewall server is deployed in front of the web applications and serves as the entry point for all public access to destination servers. Both the WAF and the servers live in close proximity to each other, allowing for optimal performance and the usage of private network links.
With the advance and massive adoption of public cloud offerings, the WAF landscape broadened from a pure infrastructure problem to hosted SaaS platforms and software solutions.
Cloud Solutions
**Hosted Platforms
**Hosted, fully managed, and API addressable WAF offerings were a significant development in WAF architecture, helping mature DevSecOps organizations automate the deployment and management of a critical security component of their network stack. The WAF is no longer a physical box, it is a software component hosted as a cloud service like many others. In that sense, availability, uptime and performance were key criteria when selecting a WAF vendor.
One of the downsides of this cloud architecture is the complexity of operations needed to flow traffic through the WAF platform. From changing the DNS records to point to the third-party SaaS, to managing SSL certificates as they need to be distributed on the trusted SaaS provider and re-originating traffic with another public endpoint into our cloud infrastructure, these are tedious tasks that often lack automation, not to mention the burden on multi-tenancy applications.
Because the third-party SaaS platform will inspect the flowing HTTP traffic, it needs to do TLS termination first. After analysis, the payload will be re-encrypted as it is forwarded on the public internet to the destination servers. Sadly a few famous attacks targeted these solutions in the past and exposed some SSL certificates and sensitive data such as in this Imperva Incapsula incident.
It is also worth mentioning the destination cloud infrastructure is still publicly available, given a different hostname, but reachable nonetheless. Attackers could use this endpoint to bypass the WAF altogether.
Cloud Providers
If you are running your applications on any of the major cloud providers, they all offer WAF solutions that tie in directly into their infrastructure. Google Cloud Armor and AWS WAF are two examples of WAF integration within the cloud provider’s load-balancing capabilities. While this option is fully managed and removes the DNS, TLS and public load-balancing choreography from third-party providers it introduces portability issues and is not well suited for multi-cloud deployment strategies.
As DevSecOps teams are changing the industry, adapting their practices to micro-services software architectures and relying more and more on Kubernetes as a platform, they are looking at ways to manage their API security with a cloud native mindset.
Protecting Your APIs the Cloud Native Way
Open initiatives such as the ModSecurity project have been around for quite some time. It influenced a movement where organizations could own the deployment of a software WAF and integrate it directly into their edge traffic proxies.
For platforms built on Kubernetes, using the Edge Stack as your API Gateway enables self-service teams to expose, secure and manage traffic to their microservices. Deploying Edge Stack API Gateway as the network entry point for your users allows you to configure TLS, Authentication and Rate Limiting filters as Kubernetes resources. Ambassador is also equipped with circuit-breakers to protect your downstream APIs and services.
Edge Stack API Gateway can also be extended with custom request filters. This functionality exemplifies advanced WAF architecture by allowing the integration of next-generation WAFs, such as the , to augment your infrastructure’s resiliency with added security coverage, while still enjoying the benefits of a fully owned platform and without the hassle of a SaaS integration.
This solution also makes it suitable for serverless application deployment, given Ambassador is controlling access to your public endpoints. The deployment strategies of this cloud native WAF architecture leads the way to automation and replication on multiple environments, including non-production installations for development and testing. With fine-grained control and a self-service platform, DevOps and Infosec teams can collaborate efficiently.
Conclusion
From our experience, we’ve seen that as more companies build cloud native applications on Kubernetes, more application developers are learning about and taking responsibility for application security, particularly by adopting modern WAF architecture. This transition of responsibility from the InfoSec team to the development team is another example of how good Kubernetes teams are enabling full cycle development.
Top comments (0)