F5 Hybrid Security Architectures (Part 3 - F5 XC API Protection and NGINX Ingress Controller)

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!

API Security:

APIs are an integral part of our daily routine, facilitating everything from critical to mundane tasks. From banking and ride-sharing apps to the weather updates we check before stepping out, APIs enable these functionalities. Given the sensitive nature of the data that can be exposed by unprotected APIs, the need for effective security cannot be stressed enough.  With F5 Distributed Cloud Web App and API protection security teams can discover, inventory, and secure these critical APIs. 

Here in this example solution, we will be using DevSecOps practices to deploy an AWS Elastic Kubernetes Service (EKS) cluster running the Brewz test web application serviced by F5 NGINX Ingress Controller.  To secure our application and APIs, we will deploy F5 Distributed Cloud's Web App and API Protection service.  This will provide us API Discovery and Security as well as a traditional Web Application Firewall and Malicious User Detection.

Distributed Cloud WAAP: Available for SaaS-based deployments and provides comprehensive security solutions designed to safeguard web applications and APIs from a wide range of cyber threats. This solution utilizes a distributed cloud architecture, which enables it to provide real-time protection and scale to meet the needs of large enterprises.

NIGNX Ingress Controller for Kubernetes: A lightweight software solution that helps manage app connectivity at the edge of a Kubernetes cluster by directing requests to the appropriate services and pods.  It provides advanced load balancing, routing, identity, and security, as well as montioring and observability features.

XC WAAP + NGINX Ingress Controller Workflow

GitHub Repo: 

F5 Hybrid Security Architectures

Prerequisites:

• F5 Distributed Cloud Account (F5 XC)
• Create an F5 XC API certificate
• NGINX Ingress Controller 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
• nic: NGINX Ingress Controller
• infra: AWS Infrastructure (VPC, IGW, etc.)
• eks: AWS Elastic Kubernetes Service
• brewz: Brewz SPA 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-nic	infra, eks, nic, brewz, xc

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
• 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

• XC_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_XC would be created with the value xc

Your GitHub Actions Secrets should resemble the following:

Setup Deployment Branch and Terraform Local Variables:

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

xc-nic deployment branch: deploy-xcapi-nic

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

#Global
project_prefix = "Your project identifier"
resource_owner = "You"

#AWS
aws_region = "Your AWS region" ex: us-west-1
azs = "Your AWS availability zones" ex: ["us-west-1a", "us-west-1b"] 

#Assets
nic = true
nap = false
bigip = false
bigip-cis = false

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

#XC Global
api_url = "https://<Your Tenant>.console.ves.volterra.io/api"
xc_tenant = "Your XC Tenant Name"
xc_namespace = "Your XC namespace"

#XC LB
app_domain = "Your App Domain"

#XC WAF
xc_waf_blocking = true

#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

#XC API Protection and Discovery
xc_api_disc = true
xc_api_pro = true
xc_api_spec = ["Path to uploaded API spec"] *See below screen shot for how to obtain this value.

#XC Bot Defense
xc_bot_def = false

#XC DDoS
xc_ddos = false

#XC Malicious User Detection
xc_mud = true

* For Path to API Spec navigate to Manage->Files->Swagger Files, click the three dots next to your OAS, and choose "Copy Latest Version's URL".  Paste this into the xc_api_spec in the xc/terraform.tfvars.

Step 4: Modify line 16 in the .gitignore and comment out the *.tfvars line with # and save the file

Step 5: Commit your changes
 

Deployment:

Step 1: Push your deploy branch to the forked repo

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

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

Step 4: Check your Terraform Outputs for XC and verify your app is available by navigating to the FQDN

API Discovery and Security Dashboards:

After leaving the Brewz test app deployed for a while we can start to see the API graph form.  The F5 XC WAAP platform learns the schema structure of the API by analyzing sampled request data, then reverse-engineering the schema to generates an OpenAPI spec.  The platform validates what is deploy versus what is discovered and tags any Shadow APIs that are found.

 

We can also check the dashboards for any attacks that may have occurred while we were waiting for discovery to finish.  The internet being what it is, it didn't take long for the platform to protect us against some attacks.

Deployment Teardown:

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

xc-nic destroy branch: destroy-xcapi-nic

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 build

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