Merge branch '326974-remove-waf-documentation' into 'master'

Remove documentation for GitLab WAF

See merge request gitlab-org/gitlab!61441

doc/topics/autodevops/customize.md

@@ -337,7 +337,6 @@ applications.
 | `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From GitLab 11.11, used to set a password to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
 | `AUTO_DEVOPS_DEPLOY_DEBUG`              | From GitLab 13.1, if this variable is present, Helm outputs debug logs. |
 | `AUTO_DEVOPS_ALLOW_TO_FORCE_DEPLOY_V<N>` | From [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image) v1.0.0, if this variable is present, a new major version of chart is forcibly deployed. For more information, see [Ignore warnings and continue deploying](upgrading_auto_deploy_dependencies.md#ignore-warnings-and-continue-deploying). |
-| `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` | From GitLab 12.5, used in combination with [ModSecurity feature flag](../../user/clusters/applications.md#web-application-firewall-modsecurity) to toggle [ModSecurity's `SecRuleEngine`](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleEngine) behavior. Defaults to `DetectionOnly`. |
 | `BUILDPACK_URL`                         | Buildpack's full URL. Can point to either [a Git repository URL or a tarball URL](#custom-buildpacks). |
 | `CANARY_ENABLED`                        | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments). |
 | `CANARY_PRODUCTION_REPLICAS`            | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. Takes precedence over `CANARY_REPLICAS`. Defaults to 1. |

doc/topics/autodevops/stages.md

@@ -645,42 +645,6 @@ ciliumNetworkPolicy:
 For more information on installing Network Policies, see
 [Install Cilium using GitLab CI/CD](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd).
 
-### Web Application Firewall (ModSecurity) customization
-
-> [Introduced](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/44) in GitLab 12.8.
-
-Customization on an [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
-or on a deployment base is available for clusters with
-[ModSecurity installed](../../user/clusters/applications.md#web-application-firewall-modsecurity).
-
-To enable ModSecurity with Auto Deploy, you must create a `.gitlab/auto-deploy-values.yaml`
-file in your project with the following attributes.
-
-|Attribute | Description | Default |
------------|-------------|---------|
-|`enabled` | Enables custom configuration for ModSecurity, defaulting to the [Core Rule Set](https://coreruleset.org/) | `false` |
-|`secRuleEngine` | Configures the [rules engine](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#secruleengine) | `DetectionOnly` |
-|`secRules` | Creates one or more additional [rule](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRule) | `nil` |
-
-In the following `auto-deploy-values.yaml` example, some custom settings
-are enabled for ModSecurity. Those include setting its engine to
-process rules instead of only logging them, while adding two specific
-header-based rules:
-
-```yaml
-ingress:
-  modSecurity:
-    enabled: true
-    secRuleEngine: "On"
-    secRules:
-      - variable: "REQUEST_HEADERS:User-Agent"
-        operator: "printer"
-        action: "log,deny,id:'2010',status:403,msg:'printer is an invalid agent'"
-      - variable: "REQUEST_HEADERS:Content-Type"
-        operator: "text/plain"
-        action: "log,deny,id:'2011',status:403,msg:'Text is not supported as content type'"
-```
-
 ### Running commands in the container
 
 Applications built with [Auto Build](#auto-build) using Herokuish, the default

doc/user/application_security/threat_monitoring/index.md

@@ -16,34 +16,8 @@ Monitoring** page.
 
 GitLab supports statistics for the following security features:
 
-- [Web Application Firewall](../../clusters/applications.md#web-application-firewall-modsecurity)
 - [Container Network Policies](../../../topics/autodevops/stages.md#network-policy)
 
-## Web Application Firewall
-
-The Web Application Firewall section provides metrics for the NGINX
-Ingress controller and ModSecurity firewall. This section has the
-following prerequisites:
-
-- Project has to have at least one [environment](../../../ci/environments/index.md).
-- [Web Application Firewall](../../clusters/applications.md#web-application-firewall-modsecurity) has to be enabled.
-- [Elastic Stack](../../clusters/applications.md#web-application-firewall-modsecurity) has to be installed.
-
-If you are using custom Helm values for the Elastic Stack you have to
-configure Filebeat similarly to the [vendored values](https://gitlab.com/gitlab-org/gitlab/-/blob/f610a080b1ccc106270f588a50cb3c07c08bdd5a/vendor/elastic_stack/values.yaml).
-
-The **Web Application Firewall** section displays the following information
-about your Ingress traffic:
-
-- The total amount of requests to your application
-- The proportion of traffic that is considered anomalous according to
-  the configured rules
-- The request breakdown graph for the selected time interval
-
-If a significant percentage of traffic is anomalous, you should
-investigate it for potential threats by
-[examining the Web Application Firewall logs](../../clusters/applications.md#web-application-firewall-modsecurity).
-
 ## Container Network Policy
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32365) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9.

doc/user/clusters/applications.md

@@ -34,7 +34,7 @@ Despite being deprecated, the recommended way for installing GitLab integrated a
 > - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 WARNING:
-The GitLab Managed Apps CI/CD installation method was [deprecated in 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/327908). 
+The GitLab Managed Apps CI/CD installation method was [deprecated in 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/327908).
 Your applications continue to work. However, we no longer support and maintain the GitLab CI/CD template for
 Managed Apps (`Managed-Cluster-Applications.gitlab-ci.yml`).
 As a replacement, we are working on a [cluster management project template](https://gitlab.com/gitlab-org/gitlab/-/issues/327908),
@@ -404,9 +404,9 @@ These values can be specified using [CI/CD variables](../../ci/variables/README.
 - `GITLAB_RUNNER_GITLAB_URL` is used for `gitlabUrl`.
 - `GITLAB_RUNNER_REGISTRATION_TOKEN` is used for `runnerRegistrationToken`
 
-The methods of specifying these values are mutually exclusive. Either specify variables `GITLAB_RUNNER_REGISTRATION_TOKEN` and `GITLAB_RUNNER_TOKEN` as CI variables (recommended) or provide values for `runnerRegistrationToken:` and `runnerToken:` in `.gitlab/managed-apps/gitlab-runner/values.yaml`. If you choose to use CI variables, comment out or remove `runnerRegistrationToken:` and `runnerToken:` from `.gitlab/managed-apps/gitlab-runner/values`.  
+The methods of specifying these values are mutually exclusive. Either specify variables `GITLAB_RUNNER_REGISTRATION_TOKEN` and `GITLAB_RUNNER_TOKEN` as CI variables (recommended) or provide values for `runnerRegistrationToken:` and `runnerToken:` in `.gitlab/managed-apps/gitlab-runner/values.yaml`. If you choose to use CI variables, comment out or remove `runnerRegistrationToken:` and `runnerToken:` from `.gitlab/managed-apps/gitlab-runner/values`.
 
-The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../ci/variables/README.md#protect-a-cicd-variable) and [masked variable](../../ci/variables/README.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml` file. 
+The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../ci/variables/README.md#protect-a-cicd-variable) and [masked variable](../../ci/variables/README.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml` file.
 
 You can customize the installation of GitLab Runner by defining
 `.gitlab/managed-apps/gitlab-runner/values.yaml` file in your cluster
@@ -1260,108 +1260,6 @@ as `*.example.com.`) to reach your apps. If your external endpoint is an IP
 address, use an A record. If your external endpoint is a hostname, use a CNAME
 record.
 
-#### Web Application Firewall (ModSecurity)
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21966) in GitLab 12.7.
-
-WARNING:
-The Web Application Firewall is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/271276)
-in GitLab 13.6, and planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/271349)
-in GitLab 14.0.
-
-A Web Application Firewall (WAF) examines traffic being sent or received,
-and can block malicious traffic before it reaches your application. The benefits
-of a WAF are:
-
-- Real-time security monitoring for your application.
-- Logging of all your HTTP traffic to the application.
-- Access control for your application.
-- Highly configurable logging and blocking rules.
-
-By default, GitLab provides you with a WAF known as [`ModSecurity`](https://www.modsecurity.org/),
-which is a toolkit for real-time web application monitoring, logging, and access
-control. GitLab applies the [OWASP's Core Rule Set](https://coreruleset.org/),
-which provides generic attack detection capabilities.
-
-This feature:
-
-- Runs in "Detection-only mode" unless configured otherwise.
-- Is viewable by checking your Ingress controller's `modsec` log for rule violations.
-  For example:
-
-  ```shell
-  kubectl -n gitlab-managed-apps logs -l app=nginx-ingress,component=controller -c modsecurity-log -f
-  ```
-
-To enable WAF, switch its respective toggle to the enabled position when installing
-or updating [Ingress application](#ingress).
-
-If this is your first time using the GitLab WAF, we recommend you follow the
-[quick start guide](../project/clusters/protect/web_application_firewall/quick_start_guide.md).
-
-There is a small performance overhead by enabling ModSecurity. If this is
-considered significant for your application, you can disable ModSecurity's
-rule engine for your deployed application in any of the following ways:
-
-1. Set the [deployment variable](../../topics/autodevops/index.md)
-   `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` to `Off` to prevent ModSecurity
-   from processing any requests for the given application or environment.
-1. Switch its respective toggle to the disabled position, and then apply changes
-   by selecting **Save changes** to reinstall Ingress with the recent changes.
-
-![Disabling WAF](../project/clusters/protect/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png)
-
-##### Logging and blocking modes
-
-To help you tune your WAF rules, you can globally set your WAF to either
-*Logging* or *Blocking* mode:
-
-- *Logging mode*: Allows traffic matching the rule to pass, and logs the event.
-- *Blocking mode*: Prevents traffic matching the rule from passing, and logs the event.
-
-To change your WAF's mode:
-
-1. If you haven't already done so,
-   [install ModSecurity](../project/clusters/protect/web_application_firewall/quick_start_guide.md).
-1. Navigate to **Operations > Kubernetes**.
-1. In **Applications**, scroll to **Ingress**.
-1. Under **Global default**, select your desired mode.
-1. Select **Save changes**.
-
-##### WAF version updates
-
-Enabling, disabling, or changing the logging mode for **ModSecurity** is only
-allowed in same version of [Ingress](#ingress) due to limitations in
-[Helm](https://helm.sh/) which might be overcome in future releases.
-
-The **ModSecurity** user interface controls are disabled if the version deployed
-differs from the one available in GitLab. However, actions at the [Ingress](#ingress)
-level, such as uninstalling, can still be performed:
-
-![WAF settings disabled](../project/clusters/protect/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png)
-
-Update [Ingress](#ingress) to the most recent version to take advantage of bug
-fixes, security fixes, and performance improvements. To update the
-[Ingress application](#ingress), you must first uninstall it, and then re-install
-it as described in [Install ModSecurity](../project/clusters/protect/web_application_firewall/quick_start_guide.md).
-
-##### Viewing Web Application Firewall traffic
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14707) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9.
-
-You can view Web Application Firewall traffic by navigating to your project's
-**Security & Compliance > Threat Monitoring** page. From there, you can see
-tracked over time:
-
-- The total amount of traffic to your application.
-- The proportion of traffic that's considered anomalous by the Web Application
-  Firewall's default [OWASP ruleset](https://coreruleset.org/).
-
-If a significant percentage of traffic is anomalous, investigate it for potential threats
-by [examining the Web Application Firewall logs](#web-application-firewall-modsecurity).
-
-![Threat Monitoring](img/threat_monitoring_v12_9.png)
-
 ### JupyterHub
 
 > - Introduced in GitLab 11.0 for project-level clusters.

doc/user/project/clusters/protect/index.md

@@ -18,9 +18,6 @@ containers themselves.
 
 The following capabilities are available to protect deployed applications in Kubernetes:
 
-- Web Application Firewall
-  - [Overview](web_application_firewall/index.md)
-  - [Installation guide](web_application_firewall/quick_start_guide.md)
 - Container Network Security
   - [Overview](container_network_security/index.md)
   - [Installation guide](container_network_security/quick_start_guide.md)

doc/user/project/clusters/protect/web_application_firewall/index.md

----
-stage: Protect
-group: Container Security
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
----
-
-# Web Application Firewall
-
-WARNING:
-The Web Application Firewall is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/271276)
-in GitLab 13.6, and planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/271349)
-in GitLab 14.0.
-
-A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to
-and from a web application. By inspecting HTTP traffic, it can prevent attacks
-stemming from web application security flaws. It can be used to detect SQL injection,
-Cross-Site Scripting (XSS), Remote File Inclusion, Security Misconfigurations, and
-much more.
-
-## Overview
-
-GitLab provides a WAF out of the box after Ingress is deployed. All you need to do is deploy your
-application along with a service and Ingress resource. In the GitLab [Ingress](../../../../clusters/applications.md#ingress)
-deployment, the [ModSecurity](https://modsecurity.org/)
-module is loaded into Ingress-NGINX by default and monitors the traffic to the applications
-which have an Ingress. The ModSecurity module runs with the [OWASP Core Rule Set (CRS)](https://coreruleset.org/)
-by default. The OWASP CRS detects and logs a wide range of common attacks.
-
-By default, the WAF is deployed in Detection-only mode and only logs attack attempts.
-
-## Requirements
-
-The Web Application Firewall requires:
-
-- **Kubernetes**
-
-  To enable the WAF, you need:
-
-  - Kubernetes 1.12+.
-  - A load balancer. You can use NGINX-Ingress by deploying it to your
-    Kubernetes cluster by either:
-    - Using the [`nginx-ingress` Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress).
-    - Installing the [Ingress GitLab Managed App](../../../../clusters/applications.md#ingress) with WAF enabled.
-
-- **Configured Kubernetes objects**
-
-  To use the WAF on an application, you need to deploy the following Kubernetes resources:
-
-  - [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
-  - [Service](https://kubernetes.io/docs/concepts/services-networking/service/)
-  - [Ingress Resource](https://kubernetes.io/docs/concepts/services-networking/ingress/)
-
-## Quick start
-
-If you are using GitLab.com, see the [quick start guide](quick_start_guide.md) for
-how to use the WAF with GitLab.com and a Kubernetes cluster on Google Kubernetes Engine (GKE).
-
-If you are using a self-managed instance of GitLab, you must configure the
-[Google OAuth2 OmniAuth Provider](../../../../../integration/google.md) before
-you can configure a cluster on GKE. Once this is set up, you can follow the steps on the
-[quick start guide](quick_start_guide.md)
-to get started.
-
-NOTE:
-This guide shows how the WAF can be deployed using Auto DevOps. The WAF
-is available by default to all applications no matter how they are deployed,
-as long as they are using Ingress.
-
-## Network firewall vs. Web Application Firewall
-
-A network firewall or packet filter looks at traffic at the Network (L3) and Transport (L4) layers
-of the [OSI Model](https://en.wikipedia.org/wiki/OSI_model), and denies packets from entry based on
-a set of rules regarding the network in general.
-
-A Web Application Firewall operates at the Application (L7) layer of the OSI Model and can
-examine all the packets traveling to and from a specific application. A WAF can set
-more advanced rules around threat detection.
-
-## Features
-
-ModSecurity is enabled with the [OWASP Core Rule Set (CRS)](https://github.com/coreruleset/coreruleset/) by
-default. The OWASP CRS logs attempts to the following attacks:
-
-- [SQL Injection](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_SQL_Injection)
-- [Cross-Site Scripting](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Cross-Site_Scripting_(XSS))
-- [Local File Inclusion](https://wiki.owasp.org/index.php/Testing_for_Local_File_Inclusion)
-- [Remote File Inclusion](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Remote_File_Inclusion)
-- [Code Injection](https://wiki.owasp.org/index.php/Code_Injection)
-- [Session Fixation](https://wiki.owasp.org/index.php/Session_fixation)
-- [Scanner Detection](https://wiki.owasp.org/index.php/Category:Vulnerability_Scanning_Tools)
-- [Metadata/Error Leakages](https://wiki.owasp.org/index.php/Improper_Error_Handling)
-
-It is good to have a basic knowledge of the following:
-
-- [Kubernetes](https://kubernetes.io/docs/home/)
-- [Ingress](https://kubernetes.github.io/ingress-nginx/)
-- [ModSecurity](https://www.modsecurity.org/)
-- [OWASP Core Rule Set](https://github.com/coreruleset/coreruleset/)
-
-## Roadmap
-
-You can find more information on the product direction of the WAF in
-[Category Direction - Web Application Firewall](https://about.gitlab.com/direction/protect/web_application_firewall/).

doc/user/project/clusters/protect/web_application_firewall/quick_start_guide.md

----
-stage: Protect
-group: Container Security
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
----
-
-# Getting started with the Web Application Firewall
-
-WARNING:
-The Web Application Firewall is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/271276)
-in GitLab 13.6, and planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/271349)
-in GitLab 14.0.
-
-This is a step-by-step guide to help you use the GitLab [Web Application Firewall](index.md) after
-deploying a project hosted on GitLab.com to Google Kubernetes Engine using [Auto DevOps](../../../../../topics/autodevops/index.md).
-
-The GitLab native Kubernetes integration is used, so you do not need
-to create a Kubernetes cluster manually using the Google Cloud Platform console.
-A simple application is created and deployed based on a GitLab template.
-
-These instructions also work for a self-managed GitLab instance. However, you
-need to ensure your own [runners are configured](../../../../../ci/runners/README.md) and
-[Google OAuth is enabled](../../../../../integration/google.md).
-
-The GitLab Web Application Firewall is deployed with [Ingress](../../../../clusters/applications.md#ingress),
-so it is available to your applications no matter how you deploy them to Kubernetes.
-
-## Configuring your Google account
-
-Before creating and connecting your Kubernetes cluster to your GitLab project,
-you need a Google Cloud Platform account. If you do not already have one,
-sign up at <https://console.cloud.google.com>. You need to either sign in with an existing
-Google account (for example, one that you use to access Gmail, Drive, etc.) or create a new one.
-
-1. To enable the required APIs and related services, follow the steps in the ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin).
-1. Make sure you have created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account).
-
-NOTE:
-Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial),
-and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with the GitLab
-Google Kubernetes Engine integration. All you have to do is [follow this link](https://cloud.google.com/partners/partnercredit/?PCN=a0n60000006Vpz4AAC) and apply for credit.
-
-## Creating a new project from a template
-
-We use a GitLab project templates to get started. As the name suggests,
-those projects provide a bare-bones application built on some well-known frameworks.
-
-1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select
-   **New project**.
-1. Go to the **Create from template** tab where you can choose for example a Ruby on
-   Rails, Spring, or NodeJS Express project.
-   Use the Ruby on Rails template.
-
-   ![Select project template](../../../../../topics/autodevops/img/guide_project_template_v12_3.png)
-
-1. Give your project a name, optionally a description, and make it public so that
-   you can take advantage of the features available in the
-   [GitLab Ultimate plan](https://about.gitlab.com/pricing/).
-
-   ![Create project](../../../../../topics/autodevops/img/guide_create_project_v12_3.png)
-
-1. Click **Create project**.
-
-Now that the project is created, the next step is to create the Kubernetes cluster
-to deploy this application under.
-
-## Creating a Kubernetes cluster from within GitLab
-
-1. On the project's landing page, click **Add Kubernetes cluster**
-   (note that this option is also available when you navigate to **Operations > Kubernetes**).
-
-   ![Project landing page](../../../../../topics/autodevops/img/guide_project_landing_page_v12_10.png)
-
-1. On the **Create new cluster on GKE** tab, click **Sign in with Google**.
-
-   ![Google sign in](../../../../../topics/autodevops/img/guide_google_signin_v12_3.png)
-
-1. Connect with your Google account and click **Allow** when asked (this
-   appears only the first time you connect GitLab with your Google account).
-
-   ![Google auth](../../../../../topics/autodevops/img/guide_google_auth_v12_3.png)
-
-1. The last step is to provide the cluster details.
-   1. Give it a name, leave the environment scope as is, and choose the GCP project under which to create the cluster.
-      (Per the instructions to [configure your Google account](#configuring-your-google-account), a project should have already been created for you.)
-   1. Choose the [region/zone](https://cloud.google.com/compute/docs/regions-zones/) to create the cluster in.
-   1. Enter the number of nodes you want it to have.
-   1. Choose the [machine type](https://cloud.google.com/compute/docs/machine-types).
-
-   ![GitLab GKE cluster details](../../../../../topics/autodevops/img/guide_gitlab_gke_details_v12_3.png)
-
-1. Click **Create Kubernetes cluster**.
-
-After a couple of minutes, the cluster is created. You can also see its
-status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
-
-The next step is to install some applications on your cluster that are needed
-to take full advantage of Auto DevOps.
-
-## Install Ingress
-
-The GitLab Kubernetes integration comes with some
-[pre-defined applications](../../index.md#installing-applications)
-for you to install.
-
-![Cluster applications](../../../../../topics/autodevops/img/guide_cluster_apps_v12_3.png)
-
-For this guide, we need to install Ingress. Ingress provides load balancing,
-SSL termination, and name-based virtual hosting, using NGINX behind
-the scenes. Make sure to switch the toggle to the enabled position before installing.
-
-Both logging and blocking modes are available for WAF. While logging mode is useful for
-auditing anomalous traffic, blocking mode ensures the traffic doesn't reach past Ingress.
-
-![Cluster applications](img/guide_waf_ingress_installation_v12_10.png)
-
-After Ingress is installed, wait a few seconds and copy the IP address that
-is displayed in order to add in your base **Domain** at the top of the page. For
-the purpose of this guide, we use the one suggested by GitLab. Once you have
-filled in the domain, click **Save changes**.
-
-![Cluster Base Domain](../../../../../topics/autodevops/img/guide_base_domain_v12_3.png)
-
-Prometheus should also be installed. It is an open-source monitoring and
-alerting system that is used to supervise the deployed application.
-Installing GitLab Runner is not required as we use the shared runners that
-GitLab.com provides.
-
-## Enabling Auto DevOps (optional)
-
-Starting with GitLab 11.3, Auto DevOps is enabled by default. However, it is possible to disable
-Auto DevOps at both the instance-level (for self-managed instances) and the group-level.
-Follow these steps if Auto DevOps has been manually disabled:
-
-1. Navigate to **Settings > CI/CD > Auto DevOps**.
-1. Select **Default to Auto DevOps pipeline**.
-1. Select the [continuous deployment strategy](../../../../../topics/autodevops/index.md#deployment-strategy)
-   which automatically deploys the application to production once the pipeline
-   successfully runs on the `master` branch.
-1. Click **Save changes**.
-
-   ![Auto DevOps settings](../../../../../topics/autodevops/img/guide_enable_autodevops_v12_3.png)
-
-Once you complete all the above and save your changes, a new pipeline is
-automatically created. To view the pipeline, go to **CI/CD > Pipelines**.
-
-![First pipeline](../../../../../topics/autodevops/img/guide_first_pipeline_v12_3.png)
-
-The next section explains what each pipeline job does.
-
-## Deploying the application
-
-By now you should see the pipeline running, but what is it running exactly?
-
-To navigate inside the pipeline, click its status badge (its status should be "Running").
-The pipeline is split into a few stages, each running a couple of jobs.
-
-![Pipeline stages](../../../../../topics/autodevops/img/guide_pipeline_stages_v13_0.png)
-
-In the **build** stage, the application is built into a Docker image and then
-uploaded to your project's [Container Registry](../../../../packages/container_registry/index.md)
-([Auto Build](../../../../../topics/autodevops/stages.md#auto-build)).
-
-In the **test** stage, GitLab runs various checks on the application.
-
-The **production** stage is run after the tests and checks finish, and it automatically
-deploys the application in Kubernetes ([Auto Deploy](../../../../../topics/autodevops/stages.md#auto-deploy)).
-
-The **production** stage creates Kubernetes objects
-like a Deployment, Service, and Ingress resource. The
-application is monitored by the WAF automatically.
-
-## Validating Ingress is running ModSecurity
-
-Now we can make sure that Ingress is running properly with ModSecurity and send
-a request to ensure our application is responding correctly. You must connect to
-your cluster either using [Cloud Shell](https://cloud.google.com/shell/) or the [Google Cloud SDK](https://cloud.google.com/sdk/docs/install).
-
-1. After connecting to your cluster, check if the Ingress-NGINX controller is running and ModSecurity is enabled.
-
-   This is done by running the following commands:
-
-   ```shell
-   $ kubectl get pods -n gitlab-managed-apps | grep 'ingress-controller'
-   ingress-nginx-ingress-controller-55f9cf6584-dxljn        2/2     Running
-
-   $ kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-apps | grep 'ingress-controller' | awk '{print $1}') -- cat /etc/nginx/nginx.conf | grep 'modsecurity on;'
-           modsecurity on;
-   ```
-
-1. Verify the Rails application has been installed properly.
-
-   ```shell
-   $ kubectl get ns
-   auto-devv-2-16730183-production     Active
-
-   $ kubectl get pods -n auto-devv-2-16730183-production
-   NAME                                   READY   STATUS    RESTARTS
-   production-5778cfcfcd-nqjcm            1/1     Running   0
-   production-postgres-6449f8cc98-r7xgg   1/1     Running   0
-   ```
-
-1. To make sure the Rails application is responding, send a request to it by running:
-
-   ```shell
-   $ kubectl get ing -n auto-devv-2-16730183-production
-   NAME  HOSTS  PORTS
-   production-auto-deploy  fjdiaz-auto-devv-2.34.68.60.207.nip.io,le-16730183.34.68.60.207.nip.io  80, 443
-
-   $ curl --location --insecure "fjdiaz-auto-devv-2.34.68.60.207.nip.io" | grep 'Rails!' --after 2 \
-          --before 2
-   <body>
-       <p>You're on Rails!</p>
-   </body>
-   ```
-
-Now that we have confirmed our system is properly setup, we can go ahead and test
-the WAF with OWASP CRS!
-
-## Testing out the OWASP Core Rule Set
-
-Now let's send a potentially malicious request, as if we were a scanner,
-checking for vulnerabilities within our application and examine the ModSecurity logs:
-
-```shell
-$ curl --location --insecure "fjdiaz-auto-devv-2.34.68.60.207.nip.io" --header "User-Agent: absinthe" | grep 'Rails!' --after 2 \
-       --before 2
-<body>
-    <p>You're on Rails!</p>
-</body>
-
-$ kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-apps | grep 'ingress-controller' | awk '{print $1}') -- cat /var/log/modsec/audit.log | grep 'absinthe'
-{
-    "message": "Found User-Agent associated with security scanner",
-    "details": {
-        "match": "Matched \"Operator `PmFromFile' with parameter `scanners-user-agents.data' against variable `REQUEST_HEADERS:user-agent' (Value: `absinthe' )",
-        "reference": "o0,8v84,8t:lowercase",
-        "ruleId": "913100",
-        "file": "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf",
-        "lineNumber": "33",
-        "data": "Matched Data: absinthe found within REQUEST_HEADERS:user-agent: absinthe",
-        "severity": "2",
-        "ver": "OWASP_CRS/3.2.0",
-        "rev": "",
-        "tags": ["application-multi", "language-multi", "platform-multi", "attack-reputation-scanner", "OWASP_CRS", "OWASP_CRS/AUTOMATION/SECURITY_SCANNER", "WASCTC/WASC-21", "OWASP_TOP_10/A7", "PCI/6.5.10"],
-        "maturity": "0",
-        "accuracy": "0"
-    }
-}
-```
-
-You can see that ModSecurity logs the suspicious behavior. By sending a request
-with the `User Agent: absinthe` header, which [absinthe](https://github.com/cameronhotchkies/Absinthe),
-a tool for testing for SQL injections uses, we can detect that someone was
-searching for vulnerabilities on our system. Detecting scanners is useful, because we
-can learn if someone is trying to exploit our system.
-
-## Conclusion
-
-You can now see the benefits of a using a Web Application Firewall.
-ModSecurity and the OWASP Core Rule Set, offer many more benefits.
-You can explore them in more detail:
-
-- [Category Direction - Web Application Firewall](https://about.gitlab.com/direction/protect/web_application_firewall/)
-- [ModSecurity](https://www.modsecurity.org/)
-- [OWASP Core Rule Set](https://github.com/coreruleset/coreruleset/)
-- [AutoDevOps](../../../../../topics/autodevops/index.md)