F5 Distributed Cloud Web App and API Protection hybrid architecture for DevSecOps

Introduction

Modern applications are known for a few distinct attributes such as design modularity, agile build processes and distributed deployments, all of which contribute to their faster time-to-market, ease of maintenance and higher adaptability.

However, with these attributes come some challenges in managing modern applications such as the inconsistencies between various organizational groups or environments, leading to inconsistent security controls protecting these applications. Often, the choice is between centrally managed but "generic" security policies and application-specific but disparate security controls.

"Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson

We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts.

In this article we will present one possible way DevSecOps can meet these challenges, using an example of deploying the F5 WAF engine in the package that is most appropriate for the intended purpose and environment while still maintaining a unified control over the deployment process.

F5 has chosen the WAF engine of its BIG-IP-based Advanced WAF to form the core of the other security products like F5 NGINX App Protect WAF and F5 Distributed Cloud Web App and API Protection (Distributed Cloud WAAP).

One WAF Engine

Each of these products come with their own strengths and are best suited for specific environments or use cases, complementing each other, so it's easy to see how combining them into tiered architectures yield robust protections that are more than just the sum of their parts.

Possible deployment options

In this example, we will explore such an architecture, intended to protect a modern modular application deployed in AWS EKS and integrated in a GitLab CI/CD pipeline.

The demo application used is Arcadia Finance, having both Web and API components packaged as Kubernetes (K8s) containers.

Design

One objective aimed with this design is to provide separate custom controls for the Web and API endpoints, acknowledging the difference in vulnerabilities and therefore security policies between these types of endpoints as illustrated by, for example, OWASP Top 10 Web App Vulnerabilities vs. OWASP Top 10 API Security.

We will use two separate instances of NGINX App Protect WAF, one implementing the Web app component security policy and the other securing the API component.

To simulate the difference in security policies, we will enforce a strict positive security model for the API security policy by automatically importing Arcadia's OpenAPI specification into the NGINX App Protect WAF instance through the CI/CD pipeline.

Another objective is to reduce the "generic" malicious traffic that is reaching these two NGINX App Protect WAF instances in the first place, by blocking this traffic as soon as possible. We will use Distributed Cloud WAAP SaaS to ensure this broad level of protection at the edge. The client connections will first go through the F5 Distributed Cloud Loadbalancer, having a security policy attached to it that is blocking the threats common to all applications exposed to the Internet, in our particular case the Web and API endpoints of Arcadia Finance but this can scale up to a large number of internal apps.

Once the traffic has been filtered for common, "generic" threats, it will be sent to the AWS EKS where NGINX App Protect WAF instances will apply specific security policies for each application or component (in our case) being protected.

A final objective of this setup is to have the security policies of NGINX App Protect WAF instances and Distributed Cloud WAAP exposed and controlled through the CI/CD pipeline such that, if changes to the security profiles are needed to mirror application development, these changes can be done in the same GitLab repo and applied through the same CI/CD pipeline that deploys the application components. This supports the Shift Left principle in securing modern apps.

Deployment details

For this demo I will be using Terraform to first deploy the underlying infrastructure on AWS and F5 Distributed Cloud and then to deploy Arcadia components to AWS EKS and configure the corresponding NGINX App Protect WAF, the F5 Distributed Cloud load balancer and Distributed Cloud WAAP policy.

In the interest of reusability, I decided to separate the Terraform module responsible for setting up the infrastructure from the rest of the demo code, you can find the repository here.

The infrastructure Terraform module (implementing the Secure Kubernetes Gateway pattern) will create a new VPC in AWS, the EKS cluster and the F5 Distributed Cloud site node that will be the link to F5 Distributed Cloud. As there is nothing application-specific to this part of the infrastructure, the Terraform module can be reused as a foundation for other deployments.

The application-specific Terraform code used in this demo can be found here, as an example. It will first call the Secure K8s Gateway Terraform module mentioned above to setup the infrastructure and then it will deploy Arcadia's K8s containers in AWS EKS along with the NGINX App Protect WAF instances and then will configure the load balancer and Distributed Cloud WAAP security policy in F5's Distributed Cloud, exposing the application to the Internet.

At this point, in a real-life scenario, multiple other apps could be deployed reusing the same underlying infrastructure.

The GitLab CI/CD pipeline ensures automatic deployment of both the app code and security profiles, keeping them in sync as the application gets developed.

variables:
    GIT_CLEAN_FLAGS: none

stages:
    - Deploy_Infrastructure
    - Deploy_Arcadia_Finance
    - Destroy_Arcadia_Finance
    - Destroy_Infrastructure    

deploy_infrastructure:
    stage: Deploy_Infrastructure
    before_script:
        - cd ${CI_PROJECT_DIR}/    
    script: 
        - terraform init
        - terraform --version
        - terraform get -update
        - rm -rf .terraform/terraform.tfstate
        - rm -f status
        - terraform plan -out=plan.out
        - terraform apply -auto-approve plan.out
    tags:
        - shell
    only:
        variables:
            - $MODE == "deploy"

deploy_arcadia_finance:
    stage: Deploy_Arcadia_Finance
    before_script:
        - cd ${CI_PROJECT_DIR}/terraform_app    
    script: 
        - terraform init
        - terraform --version
        - terraform get -update
        - rm -rf .terraform/terraform.tfstate
        - rm -f status
        - terraform plan -out=plan.out
        - terraform apply -auto-approve plan.out
    tags:
        - shell
    only:
        variables:
            - $MODE == "deploy"

destroy_arcadia_finance:
    stage: Destroy_Arcadia_Finance
    before_script:
        - cd ${CI_PROJECT_DIR}/terraform_app    
    script: 
        - terraform refresh        
        - terraform plan -destroy
        - terraform destroy -auto-approve
    tags:
        - shell
    only:
        variables:
            - $MODE == "destroy"

destroy_infrastructure:
    stage: Destroy_Infrastructure
    before_script:
        - cd ${CI_PROJECT_DIR}/    
    script: 
        - terraform refresh               
        - terraform plan -destroy
        - terraform destroy -auto-approve
    tags:
        - shell
    only:
        variables:
            - $MODE == "destroy"

You may notice the security policies for NGINX App Protect WAF are exposed in the repository with the API Security one featuring the call to load the most recent OpenAPI spec for this application.

{
  "policy": {
      "name": "policy_name",
      "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
      "applicationLanguage": "utf-8",
      "enforcementMode": "blocking",
      "signature-sets": [
          {
              "name": "High Accuracy Signatures",
              "block": true,
              "alarm": true
          }
      ],
      "bot-defense": {
          "settings": {
              "isEnabled": true
          },
          "mitigations": {
              "classes": [
                  {
                      "name": "trusted-bot",
                      "action": "alarm"
                  },
                  {
                      "name": "untrusted-bot",
                      "action": "alarm"
                  },
                  {
                      "name": "malicious-bot",
                      "action": "alarm"
                  }
              ]
          }
      },
      "open-api-files": [
          {
              "link": "https://raw.githubusercontent.com/vtobi/arcadia-finance/main/OpenAPI/open-api-spec.json"
          }
      ],
...

You may also notice the security policy for Distributed Cloud WAAP, also exposed in this repository.

resource "volterra_app_firewall" "waap-tf" {
  name                     = format("%s-waf", local.name)
  description              = format("WAF in block mode for %s", local.name)
  namespace                = local.namespace

  // One of the arguments from this list "allow_all_response_codes allowed_response_codes" must be set
  allow_all_response_codes = true
  // One of the arguments from this list "default_anonymization custom_anonymization disable_anonymization" must be set
  default_anonymization = true
  // One of the arguments from this list "use_default_blocking_page blocking_page" must be set
  use_default_blocking_page = true
  // One of the arguments from this list "default_bot_setting bot_protection_setting" must be set
  default_bot_setting = true
  // One of the arguments from this list "default_detection_settings detection_settings" must be set
  default_detection_settings = true
  // One of the arguments from this list "use_loadbalancer_setting blocking monitoring" must be set
  use_loadbalancer_setting = true
  // Blocking mode - optional - if not set, policy is in MONITORING
  blocking = true

}

For more information on available configuration options, you can check the Terraform resource documentation and the API guide. This ensures all changes to either the F5 Distributed Cloud WAAP or NGINX App Protect WAF security policies can be controlled at the CI/CD pipeline level.

Conclusion

This article was aimed at exploring an architecture combining the strengths of two ways of packaging and deploying the F5 WAF engine: using NGINX App Protect WAF and the F5 Distributed Cloud WAAP.

We saw a way to automate this deployment using a simple GitLab CI/CD pipeline and Terraform code structured in a modular way, allowing the infrastructure Terraform module to be reused for other projects.

Lastly, we briefly showed how the security policies could be modified and redeployed using the same CI/CD pipeline, keeping the security profiles in sync with the application as it is being developed.

For further information or to get started: