Beyond Ingress: How We’re Securing AI Traffic and Bridging BIG-IP with NGINX Gateway Fabric

Articles F5 Technical Articles
, , , ,
1

Introduction:

As the industry rapidly rallies behind the Kubernetes Gateway API, platform, NetOps, and SecOps teams are facing a new set of immediate architectural challenges. Instead of managing separate routing silos, enterprise teams are asking two fundamental questions:

1. How do we bring our enterprise edge (specifically our F5 BIG-IP fleet) seamlessly into modern Gateway API architectures without operational churn?

2. How do we govern and secure AI inference workloads (LLMs) running inside our clusters without drowning in sidecars, bespoke proxies, or application code changes?

With the release of F5 NGINX Gateway Fabric (NGF) 2.7, we tackled both issues head-on. By adding native support for edge-to-cluster integration and gateway-level AI security, NGINX Gateway Fabric helps organizations simplify their infrastructure while strengthening their security posture.

Below is a breakdown of why these two capabilities matter, how they work under the hood, and what the deployment workflows look like.

1. Bridging the Enterprise Edge: Introducing GatewayLink

image

The Problem It Solves

For years, teams using classic ingress controllers relied on tightly coupled integrations to bridge BIG-IP with Kubernetes. This setup gave NetOps teams their familiar, rock-solid perimeter control on BIG-IP (hardware SSL offload, massive DDoS mitigation, and global traffic management), while letting DevOps engineers route traffic dynamically inside Kubernetes.

However, microservice pods in Kubernetes are inherently ephemeral. Their IPs change constantly. Forcing external enterprise load balancers to directly track hundreds of shifting pod endpoints across multiple namespaces creates unnecessary configuration churn on the edge Application Delivery Controller (ADC) control plane—the system responsible for managing, securing, and optimizing application traffic at the network edge (in this case, your F5 BIG-IP).

Furthermore, as teams migrate to the Gateway API, they need that same clean separation of responsibilities without reinventing their ingress plumbing.

Enter GatewayLink & ExternalLoadBalancer

In NGINX Gateway Fabric 2.7, we introduced GatewayLink via an extensible ExternalLoadBalancer resource.

  • Zero-Code Integration: It bridges F5 Container Ingress Services (CIS) and NGINX Gateway Fabric without requiring custom CRD acrobatics or CIS code changes.

  • Eliminates Control Plane Churn: BIG-IP forwards external traffic to a predictable, highly stable entry point inside the cluster—the NGINX Gateway Fabric data plane pods. NGINX Gateway Fabric then handles dynamic Layer 7 routing and service discovery directly to application pods.

  • Role Separation Restored: NetOps manages edge security, certificates, and perimeter traffic on BIG-IP, while cluster operators and developers retain full autonomy using standard Gateway API resources (Gateway, HTTPRoute).

:movie_camera: Watch the Step-by-Step Walkthrough: For a complete configuration walkthrough showing how CIS discovers NGINX Gateway Fabric, connects the BIG-IP pools, and routes edge traffic to your workloads, watch the video below.
Bridging the Enterprise Edge to Kubernetes with F5 BIG-IP and NGINX Gateway Fabric

2. Securing AI Inference Traffic: Native Gateway-Level AI Guardrails

Figure 2: Secure AI traffic natively in NGINX Gateway Fabric

The Problem It Solves

Deploying Large Language Models (LLMs) and generative AI applications inside Kubernetes introduces a host of operational risks:

  • Accidental data leakage (PII, SSNs, internal IP addresses).

  • Malicious prompt injections and jailbreak attempts.

  • Compliance exposures (EU AI Act, HIPAA, GDPR).

Until now, securing these endpoints often meant either writing custom sanitization code directly inside client applications or injecting heavyweight sidecars next to every single LLM pod. That approach creates latency, fragments policy enforcement, and leaves SecOps blind to what’s happening across different clusters.

Gateway API Payload Processing with F5 AI Guardrails

In F5 NGINX Gateway Fabric release 2.7, we aligned with the Gateway API Inference Extension working group to introduce a payload processing CRD for AI traffic. Instead of bolting on sidecars, NGINX Gateway Fabric uses the PayloadProcessor Custom Resource (CR). This allows NGF to act as a centralized, high-performance inference gateway.

Key Highlights from the Setup:

1. Bidirectional Inspection: AI Guardrails inspect client prompts before they ever reach the model and inspect model outputs before they return to the user. If either violates policy, the gateway blocks traffic immediately.

2. Zero Code Changes & Zero Sidecars: The frontend application simply communicates with standard OpenAI-compatible endpoints (like /v1/chat/completions). The gateway transparently handles inspection offloading.

3. Auditing & Telemetry: When we attempt to send or leak sensitive data (such as internal IP addresses or Social Security numbers), the transaction is blocked instantaneously. This generates granular audit logs in the F5 AI Guardrails dashboard with session IDs, timestamps, and the exact policy violated.

:movie_camera: Watch the Step-by-Step Walkthrough: To see this configuration tested live against an Ollama pod running Llama 3.2, check out this video to learn more!!

F5 NGINX Gateway Fabric: Securing AI Traffic with F5 AI Guardrail

Conclusion: The Path Forward for Modern Kubernetes Architectures

The transition to the Kubernetes Gateway API isn’t just about adopting a new API spec—it’s about building a sustainable operational model that respects the distinct responsibilities of your NetOps, Platform, and SecOps teams.

By leveraging GatewayLink, you get to keep the enterprise-grade edge protections of your F5 BIG-IP fleet without forcing it to track highly volatile Kubernetes pod IPs. Simultaneously, implementing gateway-level F5 AI Guardrails via the standard Gateway API PayloadProcessor CRD ensures that your generative AI applications are compliant, secure, and shielded from prompt injections without introducing sidecar lag or forcing developers to rewrite application code.

Getting Started

If you want to test these flows yourself, here are the direct links and resources:

4

The 2.7 release is very promising with both waf, plm, the new oidc and external loadbalancer with CIS . I hope you will keep focus on the issues reported in the nginx gwfab repo.

Great Work

1 Like
5

Thank you, @KaiThor for reviewing the article. We’ll focus on the issues reported in the GitHub repo. If you’d like to see any NGF articles you’re interested in, please let us know.

1 Like