AzureFeeds

 

Azure Application Gateway for Containers is a modern, Kubernetes-native Layer 7 load balancer designed to manage ingress traffic for containerized applications running in Azure Kubernetes Service (AKS). Application Gateway for Containers is the evolution of the Application Gateway Ingress Controller (AGIC), and introduces a new control and data plane architecture, enabling near-instant updates to routes, probes, and backend pods. It supports features like traffic splitting, mutual TLS, header-based routing and increased performance—making it ideal for microservices and multi-tenant environments.

But what truly sets Application Gateway for Containers apart is its native integration with Azure Web Application Firewall (WAF). Application Gateway for Containers introduces a Kubernetes-native custom resource called WebApplicationFirewallPolicy, allowing WAF policies to be defined and scoped directly within the cluster. WAF acts as the first line of defense, inspecting all incoming traffic before it reaches your pods. WAF policies can be applied at the listener level or scoped down to specific routes, giving you precise control over how and where security is enforced. This flexibility allows security teams to deploy global protections (like the OWASP Top 10 rules for SQL injection and cross-site scripting protection) across services while also enabling developers to fine-tune route-level rules for sensitive endpoints, like /login, /upload, or /admin.

Further, Azure WAF supports prevention and detection modes, enabling you to start with alert-only configurations before moving to full enforcement allowing you to fine tune the WAF for your environment. You can also write your own rules by using the Custom Rules option. Using custom rules, you can block, allow, or log traffic based on headers, IP addresses, query parameters, or geolocation—giving security teams precise control over how threats are mitigated.

 

Let’s walk through how Azure WAF enhances security when integrated with Application Gateway for Containers. 

• Bot mitigation: Azure WAF’s bot manager uses Microsoft threat intelligence to categorize and manage bot traffic—blocking known malicious bots, allowing verified good bots, and logging unknown ones by default.


• DRS 2.1: Provides robust coverage against common web vulnerabilities, including Path Traversal, Cross-Site Scripting (XSS), SQL Injection and other OWASP Top 10 threats along with MSTIC (Microsoft Threat Intelligence Collection) rules​.


• Custom rules: You can block requests with suspicious user-agent headers, rate-limit traffic to prevent abuse, geo-block traffic from regions you don’t serve, apply header inspection, IP filtering, and more


• Real-time observability: With Application Gateway for Containers, WAF logs and metrics are integrated into your observability stack. You can correlate WAF blocks with transaction IDs, trace attack vectors end-to-end, and validate that legitimate users remain unaffected.

Let’s take a look at how you can achieve these benefits using WAF for Application Gateway for Containers:

Deploying WAF and defining WAF policies in Kubernetes:

Please make sure you have the following resources set up before getting started:

1. Azure Kubernetes Service (AKS) – Ensure your backend application is deployed and running in AKS.


2. Application Gateway for Containers – Deploy Application Gateway for Containers to manage ingress traffic to your containerized workloads.


3. WAF Policy – Create a new WAF policy or reuse an existing one already configured for Application Gateway.


4. Attach the WAF Policy – Attach the WAF policy with a new security policy under the Application Gateway for Containers settings as shown below.

Note: Security policies act as the bridge between your Azure WAF policy and the Kubernetes-native routing resources (like Gateway or HTTP Route). Without this association, the WAF policy exists in Azure but isn’t enforced on your containerized traffic.

In this example, we have setup a backend application in AKS. The setup includes:

• A namespace called test-infra


• Two services called backend-v1 and backend-v2 


• Two deployments called backend-v1 and backend-v2 

You’ll also create:

• A Gateway named gateway-01


• Two HTTP Routes:




• http-route1 for path /bar and /some/thing


• http-route2 for path /anything

 

Defining WAF policies

As mentioned earlier, Application Gateway for Containers introduces a new Kubernetes custom resource called WebApplicationFirewallPolicy which allows you to define and scope Azure WAF policies directly within your AKS cluster.

The following scopes may be defined:

• Gateway (global)


• HTTP Route (granular)

Note: These are not mutually exclusive, you can apply both a gateway-level policy and per-route policies, and the route-level policy takes precedence over the gateway-level one.

Here is an example WebApplicationFirewallPolicy YAML file:

apiVersion: alb.networking.azure.io/v1
kind: WebApplicationFirewallPolicy
metadata:
name: sample-waf-policy
namespace: test-infra
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: http-route2
namespace: test-infra
sectionNames: [“pathA”]
webApplicationFirewall:
id: /subscriptions/…/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/waf-policy-0

Note: The name field here should match the HTTP route name so it can be applied to the appropriate HTTP route when there are multiple of them.

 

Applying the policy:

To apply the policy in AKS:

kubectl apply -f waf.yaml

To verify it was applied correctly:

kubectl get webapplicationfirewallpolicy.alb.networking.azure.io -A -o yaml

The output should look like this-

apiVersion: alb.networking.azure.io/v1
kind: WebApplicationFirewallPolicy
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{“apiVersion”:”alb.networking.azure.io/v1″,”kind”:”WebApplicationFirewallPolicy”,”metadata”:{“annotations”:{},”name”:”sample-waf-policy”,”namespace”:”test-infra”},”spec”:{“targetRef”:{“group”:”gateway.networking.k8s.io”,”kind”:”HTTPRoute2″,”name”:”http-route”,”namespace”:”test-infra”},”webApplicationFirewall”:{“id”:”/subscriptions/{Subscription Name}/resourceGroups/{Resource Group Name}/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/{WAF Name}”}}}
creationTimestamp: “2025-07-17T04:50:30Z”
generation: 7
name: sample-waf-policy
namespace: test-infra
resourceVersion: “175009”
uid: 031b6b5a-96c8-4d9f-8cc0-9d5e00000
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: http-route2
namespace: test-infra
webApplicationFirewall:
id: /subscriptions/{Subscription Name}/resourceGroups/{Resource Group Name}/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/{WAF Name}
status:
conditions:
– lastTransitionTime: “2025-07-17T05:33:39Z”
message: Valid WebApplicationFirewallPolicy
observedGeneration: 7
reason: Accepted
status: “True”
type: Accepted
kind: List
metadata:
resourceVersion: “”

This confirms that the WAF policy has been applied correctly to the right HTTP Route as shown here – name: http-route2

In this scenario, we’ve configured two WAF policies:

• WAF Policy 1: Associated with http-route1, using DRS 2.1 in Prevention Mode.


• WAF Policy 2: Associated with http-route2, using a custom geo-blocking rule to deny US based traffic and is in Prevention Mode.

 

Testing WAF behavior:

In this scenario, we attempt to access the frontend URL specifically the path “/some/thing” which has the WAF Policy1 associated to it. To test the policy’s effectiveness, we simulate a SQL injection attack targeting this path as seen below. The response below demonstrates the WAF engine detecting and blocking the malicious request with an “Access Forbidden” response:

 

In the next test scenario, when a request is sent from a US-based IP address to the path /anything, we get a 403 Forbidden message. This is because WAF Policy 2 is configured with a custom geo-blocking rule to block traffic from the US region using the Client IP address. It detects the origin and blocks the request. As a result, the client receives an “Access Forbidden” response, confirming that the policy is actively enforcing geographic restrictions.

 

However, when accessing other paths such as /bar or /some/thing, the request is not blocked. This is because those paths are handled by a different route (http-route2) that is associated with WAF Policy 1, which does not include geo-blocking rules. This behavior highlights how WAF policy scoping allows you to apply different security rules to different parts of your application, enabling fine-grained control over traffic protection.

 

Note: If a specific path does not have a WAF Rule associated with it, it inherits the WAF Policy that is applied at the Global level

 

Monitoring:

While Azure WAF protects the Application Gateway for Containers, having deep visibility into traffic and threat patterns is essential for maintaining a secure and resilient application environment. To do that, we will enable diagnostic logging on the Application Gateway for Containers as shown below:

 

Once traffic hits the WAF due to an identified attack or custom rule, you will see WAF related logs using the query- “AGCFirewallLogs”. As seen, the logs provide detailed information related to the attacks such as the WAF policy that is being applied, the scope at which it is being applied, the RequestUri, RulesetType and much more.

 

Azure WAF also supports sensitive data scrubbing. For example, you can redact fields like the request IP address in the logs to maintain privacy while still capturing actionable intelligence as shown below:

 

 

As seen here, by integrating WAF logs and metrics into your observability stack, you gain real-time insights into blocked threats, user behavior, and application performance. This enables teams to trace incidents end-to-end, validate WAF effectiveness, and fine-tune policies with confidence. Whether you’re investigating a blocked request or correlating alerts with backend performance, Log Analytics empowers you to move from detection to diagnosis seamlessly.

 

Conclusion:

Azure Application Gateway for Containers paired with Web Application Firewall (WAF) offers a powerful, flexible, and Kubernetes-native approach to securing microservices at the edge.

By enabling WAF policies at both the listener and route levels, teams can enforce broad protections while tailoring defenses for high-risk endpoints. Whether you’re mitigating bots, blocking injection attacks, or applying geo-based restrictions, Application Gateway for Containers with WAF empowers you to shift security left—closer to where your services live and evolve.

Start with detection, move to prevention, and scale with confidence.

 

Next steps

• What is Application Gateway for Containers? | Microsoft Learn


• Web Application Firewall on Application Gateway for Containers | Microsoft Learn


• Default rule set 2.1 – Azure Web Application Firewall


• WAF on Azure Application Gateway bot protection overview | Microsoft Learn


• Azure Web Application Firewall (WAF) v2 custom rules on Application Gateway | Microsoft Learn