F5 Hybrid Security Architectures (Part 2 - F5's Distributed Cloud WAF and NGINX App Protect WAF)

Introduction:

For those of you following along with the F5 Hybrid Security Architectures series, welcome back! If this is your first foray into the series and would like some background, have a look at the intro article. This series is using the F5 Hybrid Security Architectures GitHub repo and CI/CD platform to deploy F5 based hybrid security solutions based on DevSecOps principles. This repo is a community supported effort to provide not only a demo and workshop, but also a stepping stone for utilizing these practices in your own F5 deployments. If you find any bugs or have any enhancement requests, open a issue or better yet contribute!

Here in this example solution, we will be using Terraform to deploy an AWS Elastic Kubernetes Service (EKS) cluster running the Arcadia Finance test web application serviced by F5 NGINX Ingress Controller for Kubernetes and protected by F5 NGINX App Protect WAF and API Protection. We will supplement this with F5 Distributed Cloud Web App and API Protection to provide complimentary security at the edge. Everything will be tied together using GitHub Actions for CI/CD and Terraform Cloud to maintain state.

Distributed Cloud WAF: Available for SaaS-based deployments in a distributed environment that reduces operational overhead with an optional fully managed service.

NIGNX App Protect WAF: A lightweight software security solution that provides high-performance, low-latency, and platform-agnostic deployments for modern, microservices-based applications and containers.

XC WAF + NGINX App Protect WAF Workflow

GitHub Repo:

F5 Hybrid Security Architectures

Prerequisites:

F5 Distributed Cloud Account (F5 XC)
Create an F5 XC API certificate
F5 NGINX Plus with NGINX App Protect WAF license
AWS Account - Due to the assets being created, free tier will not work.
Terraform Cloud Account
GitHub Account

Assets

xc: F5 Distributed Cloud WAAP
nap: NGINX Ingress Controller and NGINX App Protect WAF
infra: AWS Infrastructure (VPC, IGW, etc.)
eks: AWS Elastic Kubernetes Service
arcadia: Arcadia Finance test web application

Tools

Cloud Provider: AWS
Infrastructure as Code: Terraform
Infrastructure as Code State: Terraform Cloud
CI/CD: GitHub Actions

Terraform Cloud

Workspaces: Create a workspace for each asset in the workflow chosen

Workflow	Workspaces
xc-nap	infra, eks, nap, arcadia, xc

Workspace Sharing: Under the settings for each Workspace, set the Remote state sharing to share with each Workspace created.

Your Terraform Cloud console should resemble the following:

Variable Set: Create a Variable Set with the following values.
IMPORTANT: Ensure sensitive values are appropriately marked.

AWS_ACCESS_KEY_ID: Your AWS Access Key ID - Environment Variable
AWS_SECRET_ACCESS_KEY: Your AWS Secret Access Key - Environment Variable
AWS_SESSION_TOKEN: Your AWS Session Token - Environment Variable
VOLT_API_P12_FILE: Your F5 XC API certificate. Set this to api.p12 - Environment Variable
VES_P12_PASSWORD: Set this to the password you supplied when creating your F5 XC API key - Environment Variable
nginx_jwt: Your NGINX Java Web Token associated with your NGINX license - Terraform Variable
ssh_key: Your ssh key for access to created compute assets - Terrraform Variable
admin_src_addr: The source address of your administrative workstation - Terraform Variable
tf_cloud_organization: Your Terraform Cloud Organization name - Terraform Variable

Your Variable Set should resemble the following:

GitHub

Fork and Clone Repo: F5 Hybrid Security Architectures

Actions Secrets: Create the following GitHub Actions secrets in your forked repo

P12: The base64 encoded F5 XC API certificate
TF_API_TOKEN: Your Terraform Cloud API token
TF_CLOUD_ORGANIZATION: Your Terraform Cloud Organization
TF_CLOUD_WORKSPACE_workspace: Create for each workspace used in your workflow. EX: TF_CLOUD_WORKSPACE_NAP would be created with the value nap

Your GitHub Actions Secrets should resemble the following:

Terraform Local Variables:

Step 1: Rename infra/terraform.tfvars.examples to infra/terraform.tfvars and add the following data

project_prefix = "Your project identifier"
resource_owner = "You"
aws_region = "Your AWS region" ex: us-west-1
azs = "Your AWS availability zones" ex: ["us-west-1a", "us-west-1b"] 

#Set the following feature flags for this use case
nic = false
nap = true
bigip = false
bigip-cis = false

Step 2: Rename xc/terraform.tfvars.examples to xc/terraform.tfvars and add the following data

api_url = "https://<YOUR TENANT>.console.ves.volterra.io/api"
xc_tenant = "Your tenant id available in F5 XC Administration menu"
xc_namespace = "Your XC Namespace"
app_domain = "Your APP FQDN"

##Set the following feature flags for this usecase.

#XC WAF
xc_waf_blocking = true

#XC API Protection and Discovery
xc_api_disc = false
xc_api_pro = false
xc_api_spec = []

#XC Bot Defense
xc_bot_def = false

#XC DDoS
xc_ddos_pro = false

#XC Malicious User Detection
xc_mud = false

#XC AI/ML Settings for MUD, APIP - NOTE: Only set if using AI/ML settings from the shared namespace
xc_app_type = []
xc_multi_lb = false

Step 4: Commit your changes

Deployment Workflow:

Step 1: Check out a branch for the deploy workflow using the following naming convention

xc-nap deployment branch: deploy-xc-nap

Step 2: Push your deploy branch to the forked repo

Step 3: Back in GitHub, navigate to the Actions tab of your forked repo and monitor your build

Step 4: Once the pipeline completes, verify your assets were deployed to AWS and F5 XC

Step 5: Verify your app is available by navigating to the app domain FQDN you provided in the setup.
Note: The autocert process takes time. It may be 5 to 10 minutes before Let's Encrypt has provided the cert

F5 XC Terraform Outputs:

Destroy Workflow:

Step 1: From your main branch, check out a new branch for the destroy workflow using the following naming convention

xc-bigip destroy branch: destroy-xc-nap

Step 2: Push your destroy branch to the forked repo

Step 3: Back in GitHub, navigate to the Actions tab of your forked repo and monitor your workflow

Step 4: Once the pipeline completes, verify your assets were destroyed

Conclusion:

In this article we have shown how to utilize the F5 Hybrid Security Architectures GitHub repo and CI/CD pipeline to deploy a tiered security architecture utilizing F5 XC WAF and NGINX App Protect WAF to protect a test web application running in AWS EKS. We also provided ingress into our EKS cluster with the NGINX Ingress Controller. While the code and security policies deployed are generic and not inclusive of all use-cases, they can be used as a steppingstone for deploying F5 based hybrid architectures in your own environments.

Workloads are increasingly deployed across multiple diverse environments and application architectures. Organizations need the ability to protect their essential applications regardless of deployment or architecture circumstances. Equally important is the need to deploy these protections with the same flexibility and speed as the apps they protect. With the F5 WAF portfolio, coupled with DevSecOps principles, organizations can deploy and maintain industry-leading security without sacrificing the time to value of their applications. Not only can Edge and Shift Left principles exist together, but they can also work in harmony to provide a more effective security solution.