The Edge Challenge in Kubernetes
Kubernetes has firmly established itself as the de facto operating system for modern cloud-native workloads. Microservices architectures allow application teams to build, scale, and iterate rapidly in decoupled environments. However, as cluster density grows and hundreds of microservices are deployed across multi-tenant environments, a critical operational challenge emerges at the edge: How do you reliably publish, seamlessly control, and robustly secure application traffic entering your cluster?
Default Kubernetes abstractions such as ClusterIP and NodePort services are insufficient for production L7 traffic management. Exposing raw NodePorts creates network sprawl, while basic external load balancers lack context regarding HTTP paths, headers, authentication tokens, or web application vulnerabilities.
This is where the Kubernetes Ingress API and Ingress Controllers become vital components of modern infrastructure. An Ingress Controller acts as the single entry point (the “front door”) into the cluster, abstracting backend pod complexity while providing sophisticated Layer 7 traffic routing, TLS termination, policy enforcement, and security inspection.
Among available solutions, F5 NGINX Ingress Controller (powered by F5 NGINX Plus) stands out as an enterprise-grade solution engineered for high performance, low latency, advanced L7 traffic management, and seamless integration with F5 WAF for NGINX.
To help developers, platform teams, and security engineers get hands-on experience with these capabilities without weeks of complex setup, the F5 NGINX Ingress Controller Lab GitHub Repository is available at https://github.com/f5devcentral/NGINX-Ingress-Controller-Lab.
In this article, we frame how F5 NGINX Ingress Controller solves the Publish-Control-Secure paradigm and walk through how you can run this hands-on lab environment in minutes.
The Core Paradigm: Publish, Control, Secure
Modern Kubernetes edge management can be understood through three core pillars:
1. Publish: Bringing External Traffic to Microservices
Publishing is about making applications accessible to users outside the cluster cleanly and efficiently. The Ingress Controller handles:
- Host- and Path-Based Routing: Mapping requests (e.g.,
api.example.com/v1vs.app.example.com/dashboard) to specific internal Kubernetes services. - TLS Offloading & SNI Management: Terminating SSL/TLS certificates at the edge to encrypt traffic in transit while relieving downstream application pods from heavy cryptographic processing.
- Service Discovery Integration: Dynamically updating upstream pod IP pools as Kubernetes scales replicas up or down, without requiring static reconfigurations or reloading proxy binaries.
2. Control: Managing L7 Traffic Dynamics
Once traffic reaches the edge, operators need fine-grained control over how requests are routed and handled across life cycles:
- Traffic Splitting & Canary Releases: Routing percentages of traffic between multiple backend versions (e.g., 90% to
v1.0, 10% tov2.0) to test new features safely in production. - Rate Limiting & Throttling: Protecting backend microservices from noisy neighbors, sudden traffic spikes, or brute-force requests by enforcing request-per-second thresholds.
- Custom Resource Definitions (CRDs): Extending standard Kubernetes Ingress specs with F5 NGINX
VirtualServerandVirtualServerRouteresources, providing clean, multi-tenant declarative configuration.
3. Secure: Protecting Applications Against Threats
In a zero-trust world, exposure to the public internet requires defense-in-depth at the ingress layer:
- Authentication & Authorization: Offloading identity verification (e.g., JSON Web Tokens / JWT validation) at the ingress gateway so unauthorized requests never touch internal backend code.
- Access Control Lists (ACLs): Enforcing IP allowlists or denylists to restrict internal administrative interfaces.
- Web Application Firewall (WAF): Integrating inline, enterprise-grade threat protection via F5 WAF for NGINX to block OWASP Top 10 risks, SQL injections, Cross-Site Scripting (XSS), and zero-day vulnerabilities directly at the ingress proxy.
Fast-Tracking Learning: The F5 DevCentral Hands-On Lab
To help you put these concepts into practice, we created the open-source repository at https://github.com/f5devcentral/NGINX-Ingress-Controller-Lab.
It is designed as a turnkey, modular learning environment that guides you through real-world scenarios step-by-step.
Key Highlights of the Lab Environment
- Turnkey Setup: Works on any standard Kubernetes cluster (Minikube, K3s, EKS, GKE, AKS, or bare-metal).
- Comprehensive Use Cases: Covers 9 distinct hands-on modules ranging from basic routing and canary traffic splitting to advanced precompiled WAF policies and automated Policy Lifecycle Management (PLM).
- Declarative Configurations: Full source code and Kubernetes YAML manifests provided for every scenario.
- F5 NGINX Plus & F5 WAF for NGINX Included: Leverages F5 NGINX One evaluation licenses so you can safely test commercial features.
Getting Up and Running in Minutes
Setting up the lab environment is quick and well-documented directly within the repository.
Prerequisites
Before starting, ensure you have access to a running Kubernetes cluster with kubectl, standard utilities (git, curl, jq, and docker), and a valid NGINX Plus / NGINX One evaluation license (nginx-one-eval.crt, nginx-one-eval.key, and nginx-one-eval.jwt), requested via the F5 NGINX Trial Page.
Deployment Paths
The repository provides clear, step-by-step instructions for deployment options depending on your architecture and security requirements:
- Deployment with Precompiled WAF Policies (Recommended): Follow
DEPLOYING-WAFv5.mdto deploy F5 NGINX Ingress Controller with support for precompiled WAF policies. This is the recommended deployment model, optimizing container startup times and CPU/memory utilization (compatible with Labs 1–6 and 8). - Standard Deployment without Precompiled Policies: Follow
DEPLOYING.mdfor standard deployments without precompiled policy support (compatible with Labs 1–7). - Deployment with Policy Lifecycle Manager (PLM): Follow Lab 9 (
9.waf-plm) for a decoupled, enterprise architecture where WAF policies and attack signatures are compiled out-of-band usingcert-manager, a SeaweedFS-backed Policy Store, and the F5 WAF Policy Controller.
Simply clone the repository, choose your preferred deployment guide, and you’ll have an enterprise-ready F5 NGINX Ingress Controller with F5 WAF for NGINX up and running in minutes.
Exploring the Lab Use Cases
The lab is structured into several distinct, self-contained modules that take you from beginner concepts to advanced DevSecOps practices.
| Lab Module | Key NGINX Ingress Controller Concepts Covered |
|---|---|
| 1. Basic Ingress | Publishing services using standard Kubernetes Ingress vs. NGINX custom VirtualServer CRD, path/URI routing (/tea, /coffee), and TLS termination via Kubernetes Secrets. |
| 2. Advanced Routing | Advanced L7 traffic steering using VirtualServer route matches and conditions based on HTTP request methods ($request_method: POST) and client cookies (cookie: version=v2). |
| 3. Authentication (JWT) | Securing routes with JSON Web Token (JWT) validation using the NGINX Policy CRD (spec.jwt), JSON Web Key (JWK) ecrets, and token extraction from HTTP request headers. |
| 4. Traffic Splitting | Native weighted canary deployments and blue-green releases (e.g., 90/10 traffic splits) across upstream service versions using VirtualServer route splits. |
| 5. Access Control | Enforcing perimeter security and client IP filtering via the NGINX Policy CRD (spec.accessControl) with declarative CIDR allow and deny rules attached to VirtualServer. |
| 6. Rate Limiting | Protecting backend services against DDoS and abuse using declarative rate limiting policies (Policy CRD with spec.rateLimit), client key tracking (${binary_remote_addr}), and custom reject codes (429). |
| 7. Web Application Firewall (WAF) | Attaching embedded F5 WAF (App Protect v4) to VirtualServer via Policy CRD (spec.waf), utilizing custom user signatures (APUserSig), DataGuard policies (APPolicy), and remote syslog logging (APLogConf). |
| 8. Precompiled WAF | Next-gen F5 WAF for NGINX architecture with out-of-band compiled policy/log bundles (waf-compiler), reducing memory overhead and referencing .tgz bundles (apBundle, apLogBundle) in Policy. |
| 9. WAF with Policy Lifecycle Manager (PLM) | Enterprise WAF policy automation using f5-waf-policy-controller, SeaweedFS S3 bundle storage with cert-manager mTLS, automatic signature updates, and policy enforcement across both standard Ingress annotations and VirtualServer CRDs. |
Let’s dive into what each lab module delivers:
Lab 1: Basic Ingress, URI-Based Routing, and TLS Offload
- Objective: Learn standard Kubernetes Ingress resources.
- Scenario: Route incoming HTTP requests to multiple sample application pods based on URL paths (
/cafe,/tea) while terminating TLS at the edge with SSL certificates. - Key Learning: Understand how NGINX dynamically maps rules into high-performance
nginx.confconfigurations without dropping connections.
Lab 2: Advanced L7 Routing with NGINX Custom Resources
- Objective: Move beyond basic Kubernetes Ingress limitations using NGINX native
VirtualServerandVirtualServerRouteCRDs. - Scenario: Implement header-based routing, custom response rewrites, and multi-team routing delegation across namespaces.
- Why it Matters: Standard K8s Ingress YAML lacks advanced capabilities, often forcing teams to rely on non-portable annotations. NGINX CRDs provide clean, type-safe, and validated configurations.
Lab 3: Offloading JWT Authentication
- Objective: Secure backend APIs by verifying JSON Web Tokens (JWT) at the ingress proxy.
- Scenario: Configure NGINX to inspect HTTP Authorization headers, validate signature claims against a JSON Web Key Set (JWKS), and reject invalid requests before they reach target backend pods.
- Value: Saves developers from implementing custom token verification logic in every single microservice language/framework.
Lab 4: Zero-Downtime Traffic Splitting (Canary Deployments)
- Objective: Master progressive delivery and traffic steering.
- Scenario: Split incoming production traffic between
v1(90%) andv2(10%) of a service using declarative weights, allowing SREs to monitor telemetry before rolling out updates cluster-wide.
# Conceptual snippet from Lab 4 VirtualServer
spec:
action:
pass: target-service
upstreams:
- name: service-v1
service: app-v1-svc
port: 80
- name: service-v2
service: app-v2-svc
port: 80
routes:
- path: /version
splits:
- weight: 90
action:
pass: service-v1
- weight: 10
action:
pass: service-v2
Lab 5: Fine-Grained Access Control
- Objective: Enforce network boundary policies at Layer 7.
- Scenario: Restrict access to sensitive paths (such as
/adminor internal dashboards) by implementing IP allowlists and denylists at the custom resource level.
Lab 6: Rate Limiting & API Resiliency
- Objective: Protect backend services from denial-of-service (DoS) vectors and API exhaustion.
- Scenario: Configure client request-rate limits based on client IP or custom HTTP headers, returning custom HTTP
429 Too Many Requestsresponses when thresholds are exceeded.
Lab 7 & Lab 8: Enterprise Security with F5 WAF for NGINX
- Objective: Embed enterprise-grade security directly into your CI/CD and Kubernetes ingress architecture.
- Scenario:
- Lab 7: Deploy F5 WAF for NGINX policies using declarative YAML definitions to inspect HTTP payloads for OWASP Top 10 attacks, protocol violations, and malicious signatures.
- Lab 8: Leverage Precompiled WAF Policies compiled into binary formats using Docker. This drastically reduces NGINX pod startup time and memory footprint in large-scale Kubernetes deployments!
Lab 9: Next-Generation Policy Management with Policy Lifecycle Manager (PLM)
- Objective: Decouple WAF policy compilation, distribution, and signature updates from the ingress data plane using Policy Lifecycle Manager (PLM) and the F5 WAF for NGINX architecture.
- Scenario & Architecture: Provision
cert-managerfor automated cluster mTLS and deploy Policy Lifecycle Manager in a dedicatedplm-systemnamespace backed by an S3-compatibleSeaweedFSstorage layer. The F5 WAF Policy Controller automatically pulls attack signatures, bot signatures, and threat campaigns, and compiles declarative policies out-of-band into bundle archives. - Dual Ingress Enforcement: Deploy F5 NGINX Ingress Controller configured with App Protect v5 to seamlessly consume precompiled policy bundles from SeaweedFS S3 storage without local compilation overhead. Enforce WAF security across applications using either standard Kubernetes Ingress manifests (via
nginx.com/policiesannotations) or NGINXVirtualServercustom resources. - Threat Verification & Logging: Test both legitimate application traffic and simulated web exploits (such as Cross-Site Scripting via
<script>alert();</script>). Legitimate requests pass through smoothly, while malicious payloads are blocked inline with a Request Rejected response and unique support ID, accompanied by real-time audit event streaming directly to a centralizedsyslogreceiver. - Why it Matters: Eliminates the CPU, memory, and startup latency penalties of running policy compilers inside every edge proxy pod. Ingress Controller pods start up instantly and scale elastically under surge traffic while maintaining hardened, centrally governed, and automatically updated WAF protection.
Why This Lab Belongs in Your DevSecOps Toolkit
Whether you are evaluating F5 NGINX Ingress Controller for enterprise adoption, preparing for a Kubernetes migration, or upskilling your platform engineering team, this lab repository offers several distinct advantages:
- Zero Guesswork: Every lab includes copy-paste-ready commands, complete manifest files, and validation steps using
curl. - Production-Relevant Architecture: Uses real NGINX Plus features and commercial WAF engines rather than stripped-down mock services.
- Modular & Repeatable: Reset and run specific modules independently without needing to re-provision the entire cluster.
Conclusion & Next Steps
Exposing applications in Kubernetes is easy; publishing, controlling, and securing them effectively at enterprise scale requires the right strategy and tooling. F5 NGINX Ingress Controller bridges the gap between fast-paced microservice development and stringent platform/security requirements.
Ready to get hands-on?
- Fork or Clone the Lab: Visit github.com/f5devcentral/NGINX-Ingress-Controller-Lab.
- Request an Evaluation License: Get your free NGINX Plus trial token at f5.com/trials/nginx-one.
- Join the Conversation: Share your lab experience, questions, and feedback on F5 DevCentral!
Have you tried F5 NGINX Ingress Controller or F5 WAF for NGINX in your clusters? Let us know your thoughts in the comments below!