What this use case demonstrates
This use case covers three of the four ADSP areas: Delivery, Security, and Deployment.
- Delivery — F5 Distributed Cloud (XC) load balancer at the edge, F5 BIG-IP LTM handling traffic management inside the VPC.
- Security — XC WAF at the edge, BIG-IP Advanced WAF (AWAF) applying in-path policy before traffic reaches the application servers.
- Deployment — XC consumed as SaaS, BIG-IP deployed as a Virtual Edition in GCP. Same article, two deployment models, both provisioned from code.
You get two layers of delivery and two layers of WAF, across a SaaS edge and a self-managed VE. The whole stack, VPC through XC load balancer, comes up from a single git push.
Architecture
What gets deployed:
- A GCP VPC with management, external, internal, and application subnets
- BIG-IP with AWAF in a single-NIC configuration
- OWASP Juice Shop and crAPI as target applications
- F5 Distributed Cloud HTTP load balancer, origin pool, and WAF policy pointing at the BIG-IP
The vulnerabilities in the apps are deliberate. They let you exercise the WAF stack against real attack signatures and API abuse patterns. Without them, you only know the controls deployed, not that they work.
DevSecOps in practice
The lead-in covers the approach. For UC1, that means:
- Terraform handles infrastructure, BIG-IP configuration, and F5 Distributed Cloud objects. No click-ops.
- State lives in a GCS bucket the workflow creates on the first run, with a separate state file per module. The same bucket carries the AS3 declaration BIG-IP pulls on boot, so the runner never needs network access to BIG-IP.
- GitHub Actions runs the pipeline.
- Branch names trigger deployments, so git history shows what was meant to happen.
- GCP Workload Identity Federation replaces static service account keys.
- The F5 XC API certificate lives in GitHub Actions secrets, not the repo.
The pipeline
Pushing to a branch runs the workflow. There is no manual terraform to apply.
| Action | Branch |
|---|---|
| Validate, plan, and apply | deploy-adsp-uc1 |
| Validate only (no apply) | test-adsp-uc1 |
| Destroy all resources | destroy-adsp-uc1 |
This keeps intent visible in git, makes destroy as easy as deploying, and gives reviewers a real PR to look at when something changes.
What’s in the repo
f5devcentral/F5-ADSP-Automation:
| Directory | Purpose |
|---|---|
| infra/gcp/ | VPC, subnets, firewall rules |
| compute/gcp/ | Juice Shop and crAPI |
| f5/ | BIG-IP base config and AWAF policy |
| config/uc1/gcp/env.json | GCP project, region, prefix |
| config/uc1/xc/env.json | F5 Distributed Cloud config |
| .github/workflows/ | CI/CD workflows |
Demo
Try it
Prerequisites, secrets, and troubleshooting are in the Use Case Deployment Guide.
Contribute
Issues and PRs welcome at f5devcentral/F5-ADSP-Automation/Issues.
Resources:
F5 Application Delivery and Security Platform GitHub Repo and Automation Guide
ADSP Architecture Article Series:
Automating F5 ADSP Deployments (Intro)
Automating F5 ADSP Deployments (Part 1 - F5 XC WAF and BIG-IP Adv. WAF)
Automating F5 ADSP Deployments (Part 2 - F5 XC WAF and NGINX App Protect)
Automating F5 ADSP Deployments (Part 3 - F5 XC API Protection and NGINX Ingress)
Automating F5 ADSP Deployments (Part 4 - F5 XC API Security and NGINX Gateway Fabric)
Automating F5 ADSP Deployments (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress)
Minimizing Security Complexity: Managing Distributed WAF Policies