Add latest changes from gitlab-org/gitlab@13-8-stable-eev13.8.0-rc42

14 files changed, 61 insertions, 380 deletions

diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 7234bca8e12..78be67a5196 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -30,9 +30,12 @@ configuration. Automation enables consistency across your projects, seamless
 management of processes, and faster creation of new projects: push your code,
 and GitLab does the rest, improving your productivity and efficiency.
 
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4).
 
-For requirements, see [Requirements for Auto DevOps](requirements.md) for more information.
+For requirements, read [Requirements for Auto DevOps](requirements.md) for more information.
+
+For a developer's guide, read [Auto DevOps development guide](../../development/auto_devops.md).
 
 ## Enabled by default
 
@@ -307,6 +310,11 @@ and verifying your application is deployed as a Review App in the Kubernetes
 cluster with the `review/*` environment scope. Similarly, you can check the
 other environments.
 
+[Cluster environment scope isn't respected](https://gitlab.com/gitlab-org/gitlab/-/issues/20351)
+when checking for active Kubernetes clusters. For multi-cluster setup to work with Auto DevOps,
+create a fallback cluster with **Cluster environment scope** set to `*`. A new cluster isn't
+required. You can use any of the clusters already added.
+
 ## Limitations
 
 The following restrictions apply.
@@ -481,7 +489,7 @@ that works for this problem. Follow these steps to use the tool in Auto DevOps:
 
 ### Error: error initializing: Looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached
 
-As [announced in the official CNCF blogpost](https://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/),
+As [announced in the official CNCF blog post](https://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/),
 the stable Helm chart repository was deprecated and removed on November 13th, 2020.
 You may encounter this error after that date.
 
@@ -526,7 +534,7 @@ To fix your custom chart:
    it's used to verify the integrity of the downloaded dependencies.
 
 You can find more information in
-[issue #263778, "Migrate PostgreSQL from stable Helm repo"](https://gitlab.com/gitlab-org/gitlab/-/issues/263778).
+[issue #263778, "Migrate PostgreSQL from stable Helm repository"](https://gitlab.com/gitlab-org/gitlab/-/issues/263778).
 
 ### Error: release .... failed: timed out waiting for the condition
 
@@ -545,7 +553,7 @@ page of the deployed application on port 5000. If your application isn't configu
 to serve anything at the root page, or is configured to run on a specific port
 *other* than 5000, this check fails.
 
-If it fails, you should see these failures within the events for the relevant
+If it fails, you should see these failures in the events for the relevant
 Kubernetes namespace. These events look like the following example:
 
 ```plaintext
diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md
index 5c3b296fdea..effdb4d7b75 100644
--- a/doc/topics/autodevops/quick_start_guide.md
+++ b/doc/topics/autodevops/quick_start_guide.md
@@ -25,7 +25,7 @@ Sign in with an existing Google account, such as the one you use to access Gmail
 or Google Drive, or create a new one.
 
 1. Follow the steps described in the ["Before you begin" section](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin)
-   of the Kubernetes Engine docs to enable the required APIs and related services.
+   of the Kubernetes Engine documentation to enable the required APIs and related services.
 1. Ensure you've created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account)
    with Google Cloud Platform.
 
@@ -101,30 +101,41 @@ to deploy this project to.
 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).
 
-Next, install some applications on your cluster that are needed
-to take full advantage of Auto DevOps.
+## Install Ingress
 
-## Install Ingress and Prometheus
+After your cluster is running, you must install NGINX Ingress Controller as a
+load balancer, to route traffic from the internet to your application. Because
+you've created a Google GKE cluster in this guide, you can install NGINX Ingress Controller
+with Google Cloud Shell:
 
-After your cluster is running, you can install your first applications,
-Ingress and Prometheus:
+1. Go to your cluster's details page, and click the **Advanced Settings** tab.
+1. Click the link to Google Kubernetes Engine to visit the cluster on Google Cloud Console.
+1. On the GKE cluster page, select **Connect**, then click **Run in Cloud Shell**.
+1. After the Cloud Shell starts, run these commands to install NGINX Ingress Controller:
 
-- Ingress - Provides load balancing, SSL termination, and name-based virtual hosting,
-  using NGINX behind the scenes.
-- Prometheus - An open-source monitoring and alerting system used to supervise the
-  deployed application.
+   ```shell
+   helm repo add nginx-stable https://helm.nginx.com/stable
+   helm repo update
+   helm install nginx-ingress nginx-stable/nginx-ingress
 
-We aren't installing GitLab Runner in this quick start guide, as this guide uses the
-shared runners provided by GitLab.com.
+   # Check that the ingress controller is installed successfully
+   kubectl get service nginx-ingress-nginx-ingress
+   ```
+
+1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can
+   get the external IP address with this command:
+
+   ```shell
+   kubectl get service nginx-ingress-nginx-ingress -ojson | jq -r '.status.loadBalancer.ingress[].ip'
+   ```
 
-To install the applications:
+   Copy this IP address, as you need it in the next step.
 
-- Click the **Install** button for **Ingress**.
-- When the **Ingress Endpoint** is displayed, copy the IP address.
-- Add your **Base domain**. For this guide, use the domain suggested by GitLab.
-- Click **Save changes**.
+1. Go back to the cluster page on GitLab, and go to the **Details** tab.
+   - Add your **Base domain**. For this guide, use the domain `<IP address>.nip.io`.
+   - Click **Save changes**.
 
-![Cluster Base Domain](img/guide_base_domain_v12_3.png)
+   ![Cluster Base Domain](img/guide_base_domain_v12_3.png)
 
 ## Enable Auto DevOps (optional)
 
@@ -290,7 +301,7 @@ and then deploys the application to production.
 
 After implementing this project, you should have a solid understanding of the basics of Auto DevOps.
 You started from building and testing, to deploying and monitoring an application
-all within GitLab. Despite its automatic nature, Auto DevOps can also be configured
+all in GitLab. Despite its automatic nature, Auto DevOps can also be configured
 and customized to fit your workflow. Here are some helpful resources for further reading:
 
 1. [Auto DevOps](index.md)
diff --git a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
index c45390e935d..663060bf59d 100644
--- a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
+++ b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
@@ -161,7 +161,7 @@ For example, if the template is bundled in GitLab v13.3, change your `.gitlab-ci
 ```yaml
 include:
   - template: Auto-DevOps.gitlab-ci.yml
-  - remote: https://gitlab.com/gitlab-org/gitlab/-/blob/v13.3.0-ee/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml
+  - remote: https://gitlab.com/gitlab-org/gitlab/-/raw/v13.3.0-ee/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml
 ```
 
 ### Ignore warnings and continue deploying
@@ -181,7 +181,7 @@ the latest Auto Deploy template into your `.gitlab-ci.yml`:
 ```yaml
 include:
   - template: Auto-DevOps.gitlab-ci.yml
-  - remote: https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.latest.gitlab-ci.yml
+  - remote: https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Jobs/Deploy.latest.gitlab-ci.yml
 ```
 
 WARNING:
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index f6e0cdee2cf..6179175b4cd 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -96,7 +96,7 @@ git lfs fetch origin master
 Make sure your files aren't listed in `.gitignore`, otherwise, they will be ignored by Git thus will not
 be pushed to the remote repository.
 
-### Migrate an existing repo to Git LFS
+### Migrate an existing repository to Git LFS
 
 Read the documentation on how to [migrate an existing Git repository with Git LFS](migrate_to_git_lfs.md).
 
diff --git a/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md b/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md
index 30be9c42f01..3bd754aabfb 100644
--- a/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md
+++ b/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md
@@ -71,7 +71,7 @@ Fire up a terminal, navigate to your Git repository and:
    git push
    ```
 
-### Disabling Git Annex in your repo
+### Disabling Git Annex in your repository
 
 Before changing anything, make sure you have a backup of your repository first.
 There are a couple of ways to do that, but you can simply clone it to another
@@ -164,7 +164,7 @@ At this point, you have two options. Either add, commit and push the files
 directly back to GitLab or switch to Git LFS. We will tackle the LFS switch in
 the next section.
 
-### Enabling Git LFS in your repo
+### Enabling Git LFS in your repository
 
 Git LFS is enabled by default on all GitLab products (GitLab CE, GitLab EE,
 GitLab.com), therefore, you don't need to do anything server-side.
diff --git a/doc/topics/git/lfs/migrate_to_git_lfs.md b/doc/topics/git/lfs/migrate_to_git_lfs.md
index 941fc281e4c..ef2675db6d4 100644
--- a/doc/topics/git/lfs/migrate_to_git_lfs.md
+++ b/doc/topics/git/lfs/migrate_to_git_lfs.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 description: "How to migrate an existing Git repository to Git LFS with BFG."
 ---
 
-# Migrate a Git repo into Git LFS with BFG
+# Migrate a Git repository into Git LFS with BFG
 
 Using Git LFS can help you to reduce the size of your Git
 repository and improve its performance.
@@ -38,7 +38,6 @@ Before beginning, make sure:
   Storage is required for the entire history of all files.
 - All the team members you share the repository with have pushed all changes.
   Branches based on the repository before applying this method cannot be merged.
-  Branches based on the repo before applying this method cannot be merged.
 
 To follow this tutorial, you need:
 
@@ -74,7 +73,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
 1. Clone `--mirror` the repository:
 
    Cloning with the mirror flag creates a bare repository.
-   This ensures you get all the branches within the repo.
+   This ensures you get all the branches within the repository.
 
    It creates a directory called `<repo-name>.git`
    (in our example, `test-git-lfs-repo-migration.git`),
diff --git a/doc/topics/git/numerous_undo_possibilities_in_git/index.md b/doc/topics/git/numerous_undo_possibilities_in_git/index.md
index 8fc2259c83e..f6571c7b277 100644
--- a/doc/topics/git/numerous_undo_possibilities_in_git/index.md
+++ b/doc/topics/git/numerous_undo_possibilities_in_git/index.md
@@ -493,6 +493,8 @@ An alternative is the open source community-maintained tool [BFG](https://rtyley
 Keep in mind that these tools are faster because they do not provide the same
 feature set as `git filter-branch` does, but focus on specific use cases.
 
+Refer [Reduce repository size](../../../user/project/repository/reducing_the_repo_size_using_git.md) page to know more about purging files from repository history & GitLab storage.
+
 ## Conclusion
 
 There are various options of undoing your work with any version control system, but
diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md
index 590a37d0128..fa42cfd6e5b 100644
--- a/doc/topics/git/partial_clone.md
+++ b/doc/topics/git/partial_clone.md
@@ -229,7 +229,7 @@ remove filtering:
    `pack-<SHA1>.promisor` file, which should be empty and should be deleted.
 
 1. Remove partial clone configuration. The partial clone-related configuration
-   variables should be removed from Git config files. Usually only the following
+   variables should be removed from Git configuration files. Usually only the following
    configuration must be removed:
    - `remote.origin.promisor`.
    - `remote.origin.partialclonefilter`.
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md
index 292e35922d6..87d8129dc7f 100644
--- a/doc/topics/gitlab_flow.md
+++ b/doc/topics/gitlab_flow.md
@@ -22,7 +22,7 @@ It offers a simple, transparent, and effective way to work with Git.
 
 When converting to Git, you have to get used to the fact that it takes three steps to share a commit with colleagues.
 Most version control systems have only one step: committing from the working copy to a shared server.
-In Git, you add files from the working copy to the staging area. After that, you commit them to your local repo.
+In Git, you add files from the working copy to the staging area. After that, you commit them to your local repository.
 The third step is pushing to a shared remote repository.
 After getting used to these three steps, the next challenge is the branching model.
 
diff --git a/doc/topics/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png b/doc/topics/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png
deleted file mode 100644
index 2dd6df3d37b..00000000000
--- a/doc/topics/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png
+++ /dev/null
diff --git a/doc/topics/web_application_firewall/img/guide_waf_ingress_installation_v12_10.png b/doc/topics/web_application_firewall/img/guide_waf_ingress_installation_v12_10.png
deleted file mode 100644
index e88f62a2eba..00000000000
--- a/doc/topics/web_application_firewall/img/guide_waf_ingress_installation_v12_10.png
+++ /dev/null
diff --git a/doc/topics/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png b/doc/topics/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png
deleted file mode 100644
index 1c99d4f7f96..00000000000
--- a/doc/topics/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png
+++ /dev/null
diff --git a/doc/topics/web_application_firewall/index.md b/doc/topics/web_application_firewall/index.md
index 1c1728d9277..297b2f7eaaa 100644
--- a/doc/topics/web_application_firewall/index.md
+++ b/doc/topics/web_application_firewall/index.md
@@ -1,97 +1,8 @@
 ---
-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
+redirect_to: '../../user/project/clusters/protect/web_application_firewall/index.md'
 ---
 
+This document was moved to [another location](../../user/project/clusters/protect/web_application_firewall/index.md).
 
-# Web Application Firewall - ModSecurity
-
-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](../../user/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](../../user/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 need to 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/).
+<!-- This redirect file can be deleted after <2021-04-01>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/topics/web_application_firewall/quick_start_guide.md b/doc/topics/web_application_firewall/quick_start_guide.md
index df355ff2413..4d7244f88fa 100644
--- a/doc/topics/web_application_firewall/quick_start_guide.md
+++ b/doc/topics/web_application_firewall/quick_start_guide.md
@@ -1,258 +1,8 @@
 ---
-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
+redirect_to: '../../user/project/clusters/protect/web_application_firewall/quick_start_guide.md'
 ---
 
-# Getting started with the Web Application Firewall
+This document was moved to [another location](../../user/project/clusters/protect/web_application_firewall/quick_start_guide.md).
 
-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](../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](../../user/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 barebones 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](../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 Gold plan](https://about.gitlab.com/pricing/#gitlab-com).
-
-   ![Create project](../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](../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](../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](../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](../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](../../user/project/clusters/index.md#installing-applications)
-for you to install.
-
-![Cluster applications](../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](../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](../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](../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](../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](../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](../../user/packages/container_registry/index.md) ([Auto Build](../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](../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](../autodevops/index.md)
+<!-- This redirect file can be deleted after <2021-04-01>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->