WAF 301 - AWAF in a CI/CD Pipeline (Self Guided)¶
Welcome to F5’s Agility Labs, 2022 edition! This class will focus on how to integrate F5 AWAF into a CI/CD pipeline.
By the end of this lab you should be able to:
- Create an AWAF template
- Properly test the template
- Enable SRE’s to deploy applications using your template
- Enable SRE’s to make custom changes to the WAF policy
In order to successfully complete the lab you should have a basic understanding of some of the DevOps methodologies and tools,
Source Control Management (SCM) (or version control) is the practice of tracking and managing changes to code. Source control management (SCM) systems provide a running history of code development and help to resolve conflicts when merging contributions from multiple sources.
Infrastructure as Code (IaC) is a set of configurations, policies, and profiles considered to be a “deployment artifacts” and can be treated just like code. That means they can be stored and managed in repositories, versioned, and reviewed. They can be pulled, cloned, and committed in the same way a developer pulls, clones, and commits code to and from a repository (like Github).
Continuos Integration/Continuos Deployment (CI/CD) works by pushing small code chunks to your application’s code base hosted in a Git repository, and, to every push, run a pipeline of scripts to build, test, and validate the code changes before merging them into the main branch. Continuous Delivery and Deployment consist of a step further CI, deploying your application to production at every push to the default branch of the repository. These methodologies allow you to catch bugs and errors early in the development cycle, ensuring that all the code deployed to production complies with the code standards you established for your app.
Two main features that make AWAF to DevSecOps integration frictionless¶
- Declarative AWAF policy expressed as a YAML or JSON blob
- Outgoing webhooks for Slack and MS Teams
Declarative AWAF policy YAML/JSON file can be used in place of a legacy XML policy (XML policy is still supported) and can be easily applied to an app following the same pipeline of the DevOps toolchain. Policy can be kept in SCM alongside with app source code, and be used by CI server in a traditional DevOps deployment model. Since JSON and YAML are trivially mapped (and JSON can be converted to YAML and vice versa), AWAF supports both file types. For the purpose of this lab our WAF policy is expressed as a JSON blob.
AWAF policy overview¶
AWAF policy consists of 3 parts:
- Baseline policy
Baseline policy part defines basic parameters - name, description and a template used for this policy
In the future it will be possible to reference an externally hosted policy
Adjustments part defines overrides and/or additions to the baseline policy. This include any blocking settings overrides, signature settings and outgoing webhooks
Modifications policy part defines individual actions that modify the policy based on AWAF learning or other actions like DAST resolutions
New feature in 15.1 allows AWAF to use outgoing webhooks to send notifications to a Slack or MS Teams channels. This makes a great addition to a commonly-used “ChatOps” method where Devs, DevOps and DevSecOps monitor a particular channel for any notifications raised by SCM, WAF, Ci server etc. Webhooks are defined explicitly inside the AWAF policy and can be triggered by a number of different events. Notification messages are configurable and may contain various useful information about the event. AS it applies to AWAF, notification message can be sent when the policy has been applied, or a security event has been observed:
Webhooks are not used in this lab
During this lab you will work with GitLab CE and utilize SCM and CI/CD pipelines to build, test and deploy ‘OWASP Juice-Shop’ App into a Docker host fronted by BIG-IP AWAF.
You use AWAF suggestions for trusted traffic to modify WAF policy and re-deploy the app all the way to Production.