--- title: "Calico workload-centric web application firewall (WAF): A better way to secure cloud-native applications" source: "https://www.tigera.io/blog/calico-workload-based-web-application-firewall-waf-a-better-way-to-secure-cloud-native-applications/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Calico workload-centric web application firewall (WAF): A better way to secure cloud-native applications By [Joseph Yostos](https://www.tigera.io/blog/author/joseph-yostos/) on Jul 12, 2022 • 6 min read Container-based web applications built on microservices architecture, whether public-facing or internal, are critical to businesses. This new class of applications is commonly referred to as cloud-native applications. Read on to find out why traditional WAFs are no longer enough to protect cloud-native applications and how Calico’s new workload-centric WAF solves this problem. ## Background HTTP is the lingua franca for modern, RESTful APIs and microservices communication. Traditionally, organizations have deployed WAF at the perimeter level to protect web applications against external attacks. A WAF provides visibility and enforces security controls on external traffic that passes through it. However, for cloud-native applications, where the concept of a perimeter does not exist, the same visibility and control need to be provided at the workload level inside the cluster. In a survey conducted by information security research center Ponemon Institute to probe the state of the WAF market, more than 600 respondents noted the following: - 86% of organizations experienced application-layer attacks that bypassed their WAF in the last 12 months. - While 66% of respondents consider WAF to be an important security tool, over 40% use their WAFs only to generate alerts (not to block attacks). *Source: Ponemon Institute – “The State of Web Application Firewalls” (14 May 2019)* The indisputable conclusion from the above response is that WAFs are still relevant, even for a cloud-native application—but traditional WAFs need an overhaul in terms of architecture and context-based alerts. A perimeter-based WAF is inadequate to secure cloud-native applications, which are vulnerable to both external threats as well as threats from lateral movement inside the cluster. Modern cloud-native applications require web application protection at the granular workload level. To keep these cloud-native applications secure, we need to analyze all HTTP communication at a workload level to block any malicious traffic transmitting to the application or moving laterally within the application. ## Calico workload-centric WAF Calico’s workload-centric WAF takes a unique, cloud-native approach to application and API-layer security by allowing you to implement policies at the workload level to protect applications from malicious lateral movement within the cluster or external communication over the internet. Calico WAF works across any Kubernetes-based platforms, multi-cloud, and hybrid environments. You can also monitor application and API traffic within your cluster with Calico WAF, leveraging a core ruleset that protects workloads against common OWASP Top 10 threats including SQL injection and cross-site scripting. You can also configure custom rule sets to look for things like unexpected content types that may be indicative of a compromise. For increased protection, you can use Calico security policies to enforce security controls to block traffic on selected pods on the host. In addition to protecting against application-layer attacks, any blocked HTTP requests are logged and made available in Elasticsearch for review. You can also trigger alerts based on these logs. Let’s have an in-depth look at how Calico WAF works. ### A purpose-built design When we think of traffic traversing a cloud-native application, it is fair to assume it includes a bulk of HTTP traffic entering and leaving your Kubernetes clusters. The WAF we have all known so far—that sits at the edge of the cluster—is not going to inspect any of this HTTP traffic that might flow between the pods within a cluster. Inspecting any traffic at the application layer is resource-intensive and must be carried out at all possible perimeters of a cloud-native application. By leveraging Calico’s Envoy proxy and placing the WAF at the workload level instead of just outside the cluster, the workload WAF provides well-rounded visibility into all traffic, no matter its origin and direction. ### Architecture Calico’s workload-centric WAF plugs into our existing Envoy proxy, which runs as a DaemonSet alongside Calico. Calico proxies select service traffic through Envoy, checking HTTP requests using the industry-standard ModSecurity module. This type of architecture enables the WAF to be deployed and protect against potential threats in service-to-service communication, without leaving the perimeter of the cluster or the node. This diagram shows how both external and internal traffic is redirected to be filtered using Calico WAF: ![Diagram showing Calico WAF filtering internal & external traffic to a Kubernetes web app, routing through service (SVC) on](https://www.tigera.io/app/uploads/2022/07/image4.png) ### Configuration You can enable WAF in your cluster by deploying ApplicationLayer resource (as a custom resource definition) and enabling `webApplicationFirewall`. ``` apiVersion: operator.www.tigera.io/v1 kind: ApplicationLayer metadata: name: tigera-secure spec: webApplicationFirewall: Enabled ``` You may have the ApplicationLayer resource already deployed in your cluster if you have application-layer logs enabled. In this case, you can just update the existing deployed resource to enable `webApplicationFirewall`. ### Monitor, detect, and block attacks You can select traffic for WAF by annotating the services as shown below. By only annotating certain services, you can customize and fine tune WAF rules to a more granular level to lower false positives. The WAF only blocks annotated traffic for policy violations, hence you should ensure the correct service is annotated. ``` kubectl annotate svc -n projectcalico.org/l7-logging=true ``` Let’s see how Calico can detect a common OWASP violation of a SQL injection to an online e-commerce web application and block this communication. A regular curl command without any code injection is first shown, with a 200 OK result: ![Curl command showing a successful (200 OK) HTTP request to an e-commerce site, illustrating a baseline before SQL injection](https://www.tigera.io/app/uploads/2022/07/image1.png) Here, a piece of code was added in the end to get user information, mimicking an attacker’s attempt. It was immediately detected and blocked by Calico: ![Screenshot of a terminal showing a blocked SQL injection attempt; Calico's response is a 403 Forbidden error](https://www.tigera.io/app/uploads/2022/07/image2.png) ### Alerts In addition to protecting against application-layer attacks, any blocked HTTP requests will be logged and be available for review in Elasticsearch. You can also set Global Alerts to be triggered based on these logs. You can see the relevant WAF assessment from any request in Kibana: ![Kibana screenshot showing WAF assessment data retrieved from a request, including details like timestamp, IP addresses, and](https://www.tigera.io/app/uploads/2022/07/image3.png) You can also create a Global Alert for WAF using Manager UI or standard YAML. Here is an example of a Global Alert for an SQL injection attack, specifically Rule ID 942100: ``` apiVersion: projectcalico.org/v3 kind: GlobalAlert metadata: name: waf-new-alert-rule-info spec: summary: "WAF new waf-alert-942100" description: "Test WAF Global Alert" severity: 1 dataSet: waf period: 1m lookback: 1h query: '"rule_info" IN {"*942100*"}' threshold: 0 condition: gt ``` Now, if an SQL injection attack is detected for rule ID 942100, you will see the Global Alert in the Manager UI under **Activity** > **Alerts**. ![Screenshot of an alert list showing details of an SQL injection attack (rule ID 942100) detected by WAF](https://www.tigera.io/app/uploads/2022/07/image5.png) ## Conclusion The complexity and distributed nature of cloud-native applications have rendered traditional, centralized WAF deployments inadequate. On one hand, trying to improve the effect of false positives on the WAF can help with the existing challenge of a lack of security tool management resources. On the other hand, dropping critical services from the detection list can also result in fatal exploits inside and outside of a microservice cluster. At Tigera, we understand both sides of this fundamental problem, which is why we have addressed it with a modern approach and architecture. Click [here](https://docs.tigera.io/calico-enterprise/latest/threat/web-application-firewall) to read more about our workload-centric web application firewall. ***Interested in seeing how Calico’s workload-centric WAF works for a cloud-native application? [Contact us](https://www.tigera.io/contact/) for a live demo.*** [Products](https://www.tigera.io/tags/products/)[Release](https://www.tigera.io/tags/release/) ## Related posts [![Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/app/uploads/2026/09/Meet-Mylo-An-AI-native-way-to-work-with-Calico.png)](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) #### [Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) By [Phil DiCorpo](https://www.tigera.io/blog/author/phil-dicorpo/) on Sep 3, 2026 A library of Calico tools and skills — delivered through the Calico MCP Server What if your hardest network question took ten minutes instead of ten days? Anyone who has operated Kubernetes networking at scale... [Read more](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) [![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) #### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 27, 2026 Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a... [Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) [![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) #### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 24, 2026 The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms... [Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)