Calico workload-centric web application firewall (WAF): A better way to secure cloud-native applications

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:

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 <service-name> -n <service-namespace> 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:

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:

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:

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.

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 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 for a live demo.

Join our mailing list

Get updates on blog posts, workshops, certification programs, new releases, and more!

X