F5 WAF on NGINX Gateway Fabric: Container-Native WAF for the Kubernetes Gateway API

Articles F5 Technical Articles
, , ,
1

The Kubernetes Gateway API is quickly becoming the standard for managing ingress and traffic routing — replacing the older Ingress resource with a more expressive, role-oriented model. But while the Gateway API provides platform teams with powerful traffic management, it comes with limited built-in application-layer security. It handles routing. Protection is not included.

F5 WAF for NGINX Gateway Fabric closes that gap. It brings enterprise-grade WAF protection directly into the Kubernetes data plane — container-native, declaratively managed, and integrated with NGINX One Console for centralized policy management.

In this article, I’ll walk through the end-to-end workflow: creating a WAF policy in NGINX One Console, applying it to F5 NGINX Gateway Fabric, blocking a live XSS attack, and masking sensitive data with DataGuard — all without changing a single line of application code.

Why WAF at the Gateway?

Traditional WAF deployments were designed for monolithic architectures — sitting at the network perimeter, inspecting traffic before it reached a handful of servers. In Kubernetes, applications are distributed across dozens or hundreds of microservices, each with its own API surface. The perimeter model doesn’t scale.

F5 WAF for NGINX Gateway Fabric embeds security directly into the data plane. Every HTTPRoute behind the gateway gets WAF protection — declaratively, through the same Kubernetes-native workflows your platform team already uses.

Key capabilities:

  • Container-native — runs natively with NGINX Gateway Fabric, no sidecar required
  • OWASP Top 10 protection with advanced attack signatures
  • REST, GraphQL, and gRPC API protection
  • DataGuard — automatic PII masking in API responses
  • Centralized management through NGINX One Console

image_346839.gif

NGINX One Console Integration

The integration between NGINX Gateway Fabric and NGINX One Console is what makes this solution practical for real-world operations. It creates a clean separation between security policy ownership and application deployment.

Policy Management

SecOps teams create and manage WAF policies entirely within NGINX One Console — using the visual form editor or the JSON tab for advanced configurations. Policies are defined once and consumed by any number of gateways. There’s no need for SecOps to touch Kubernetes resources or learn YAML.

image_346839.png
image_346839.png907×948 73.5 KB

[Screenshot: NGINX One Console — WAF Policy editor showing waf-policy with blocking mode and NGINX Base template]

The console supports policy presets (like NGINX Strict for aggressive blocking), custom violation rules, attack signature set configuration, and application-specific exceptions. Once a policy is saved, it compiles instantly and generates an Object ID that platform teams reference from Kubernetes.

Security Dashboard

Every WAF event — blocked attacks, DataGuard alerts, policy violations — flows back to the Security Dashboard in real time. SecOps gets full visibility without leaving the console.

image_346839.png
image_346839.png898×734 96.1 KB

Screenshot: NGINX One Console — Security Dashboard showing both waf-policy and dataguard-blocking policies, top violations, XSS signatures

The dashboard surfaces:

  • Attack types, blocked requests, and violation counts per policy
  • Top attack signatures — including XSS, SQLi, and bot patterns
  • Attacker IP addresses and targeted endpoints
  • Event drilldown with raw request payloads and signature match details

For incident response, the Event Logs tab provides full forensic detail — the raw request, violation rating, matched signatures with accuracy and risk classification, and the support ID returned to the attacker.

image_346839.png
image_346839.png823×989 49.5 KB

[Screenshot: Security Event drilldown — blocked XSS request showing raw payload, max severity rating, signature details

Log Profiles

Security logging is configured as part of the WAF policy configuration. Logs are sent back to NGINX One Console using the secops_dashboard log profile, which feeds the Security Dashboard. This means every gateway running the policy contributes to the same centralized view — no separate log aggregation needed.

Automatic Policy Updates

When SecOps updates a policy — adding a new signature set, tightening a violation rule, or enabling DataGuard — NGINX Gateway Fabric detects the change automatically. The updated policy propagates to every gateway that references it. No pod restarts, no redeployments, no manual sync.

This is the operating model: SecOps owns the security posture in the console. Platform teams consume it declaratively in Kubernetes. Both teams work independently without stepping on each other.

How It Works — The WAFPolicy Resource

The connection between NGINX One Console and NGINX Gateway Fabric is established via a WAFPolicy custom resource. This is the only Kubernetes resource the platform team needs to apply.

The WAFPolicy does three things:

  • Points the gateway to the specific policy created in NGINX One Console (by Object ID)
  • Provides secure credentials to pull the policy (via a Kubernetes secret)
  • Routes security events back to the console for the Security Dashboard
apiVersion: gateway.nginx.org/v1alpha1
kind: WAFPolicy
metadata:
  name: gateway-base-protection
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway
  type: N1C
  policySource:
    n1cSource:
      url: https://your-console.example.com
      namespace: your-namespace
      policyObjectID: pol_xxxxxxxxxxxxx
      auth:
        secretRef:
          name: n1c-credentials
  securityLogs:
    - destination:
        type: syslog
        syslog:
          server: localhost:1514
      logSource:
        n1cSource:
          url: https://your-console.example.com
          namespace: your-namespace
          profileName: "secops_dashboard"
          auth:
            secretRef:
              name: n1c-credentials

Once applied, the gateway status confirms the policy is active:

$ kubectl describe wafpolicy gateway-base-protection
...
Status:
  Conditions:
    Message:  The Policy is accepted
    Reason:   Accepted
    Status:   True
    Message:  Policy is programmed in the data plane
    Reason:   Programmed
    Status:   True

All traffic through the gateway is now inspected by F5 WAF.

Demo Walkthrough

The video below demonstrates the complete workflow — from policy creation to attack blocking to DataGuard masking. Here’s a summary of what you’ll see.

Resources

1 Like