Add latest changes from gitlab-org/gitlab@master

10 files changed, 174 insertions, 131 deletions

diff --git a/doc/README.md b/doc/README.md
index d5ffe7dd0f2..56e70bb1779 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -55,7 +55,7 @@ making the software lifecycle faster and radically improving the speed of busine
 
 GitLab provides solutions for [each of the stages of the DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/):
 
-![DevOps Stages](img/devops-stages.png)
+![DevOps Stages](img/devops-stages-13_3.png)
 
 GitLab is like a top-of-the-line kitchen for making software. As the executive
 chef, you decide what software you want to serve. Using your recipe, GitLab handles
@@ -71,10 +71,11 @@ The following sections provide links to documentation for each DevOps stage:
 | [Create](#create)       | Source code, data creation, and management features.        |
 | [Verify](#verify)       | Testing, code quality, and continuous integration features. |
 | [Package](#package)     | Docker container registry.                                  |
+| [Secure](#secure)       | Security capability features.                               |
 | [Release](#release)     | Application release and delivery features.                  |
 | [Configure](#configure) | Application and infrastructure configuration tools.         |
 | [Monitor](#monitor)     | Application monitoring and metrics features.                |
-| [Secure](#secure)       | Security capability features.                               |
+| [Defend](#defend)       | Protection against security intrusions.                     |
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#overview">
@@ -274,6 +275,30 @@ The following documentation relates to the DevOps **Package** stage:
   </a>
 </div>
 
+### Secure
+
+Check your application for security vulnerabilities that may lead to unauthorized access, data
+leaks, or denial of service. GitLab can perform static and dynamic tests on your application's code,
+looking for known flaws and reporting them in the merge request. You can then fix flaws prior to
+merge. Security teams can use dashboards to get a high-level view on projects and groups, and start
+remediation processes when needed.
+
+The following documentation relates to the DevOps **Secure** stage:
+
+| Secure topics                                                                                         | Description                                                            |
+|:------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------|
+| [Compliance Dashboard](user/compliance/compliance_dashboard/index.md) **(ULTIMATE)**        | View the most recent Merge Request activity in a group.                |
+| [Container Scanning](user/application_security/container_scanning/index.md) **(ULTIMATE)**            | Use Clair to scan Docker images for known vulnerabilities.             |
+| [Dependency List](user/application_security/dependency_list/index.md) **(ULTIMATE)**                  | View your project's dependencies and their known vulnerabilities.      |
+| [Dependency Scanning](user/application_security/dependency_scanning/index.md) **(ULTIMATE)**          | Analyze your dependencies for known vulnerabilities.                   |
+| [Dynamic Application Security Testing (DAST)](user/application_security/dast/index.md) **(ULTIMATE)** | Analyze running web applications for known vulnerabilities.            |
+| [Group Security Dashboard](user/application_security/security_dashboard/index.md#group-security-dashboard) **(ULTIMATE)**      | View vulnerabilities in all the projects in a group and its subgroups. |
+| [Instance Security Dashboard](user/application_security/security_dashboard/index.md#instance-security-dashboard) **(ULTIMATE)**      | View vulnerabilities in all the projects you're interested in. |
+| [License Compliance](user/compliance/license_compliance/index.md) **(ULTIMATE)**            | Search your project's dependencies for their licenses.                 |
+| [Pipeline Security](user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**    | View the security reports for your project's pipelines.               |
+| [Project Security Dashboard](user/application_security/security_dashboard/index.md#project-security-dashboard) **(ULTIMATE)**    | View the latest security reports for your project.                     |
+| [Static Application Security Testing (SAST)](user/application_security/sast/index.md) **(ULTIMATE)**  | Analyze source code for known vulnerabilities.                         |
+
 ### Release
 
 Spend less time configuring your tools, and more time creating. Whether you’re
@@ -352,29 +377,21 @@ The following documentation relates to the DevOps **Monitor** stage:
   </a>
 </div>
 
-### Secure
+### Defend
 
-Check your application for security vulnerabilities that may lead to unauthorized access,
-data leaks, and denial of services. GitLab will perform static and dynamic tests on the
-code of your application, looking for known flaws and report them in the merge request
-so you can fix them before merging. Security teams can use dashboards to get a
-high-level view on projects and groups, and start remediation processes when needed.
+GitLab Defend enables organizations to proactively protect cloud-native environments by providing
+context-aware technologies to reduce overall security risk. Defend is a natural extension of your
+existing operation's practices and provides security visibility across the entire DevSecOps
+lifecycle. This empowers your organization to apply DevSecOps best practices from the first line of
+code through monitoring and protecting your applications deployed into production.
 
-The following documentation relates to the DevOps **Secure** stage:
+The following documentation relates to the DevOps **Defend** stage:
 
-| Secure topics                                                                                         | Description                                                            |
+| Defend topics                                                                                         | Description                                                            |
 |:------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------|
-| [Compliance Dashboard](user/compliance/compliance_dashboard/index.md) **(ULTIMATE)**        | View the most recent Merge Request activity in a group.                |
-| [Container Scanning](user/application_security/container_scanning/index.md) **(ULTIMATE)**            | Use Clair to scan Docker images for known vulnerabilities.             |
-| [Dependency List](user/application_security/dependency_list/index.md) **(ULTIMATE)**                  | View your project's dependencies and their known vulnerabilities.      |
-| [Dependency Scanning](user/application_security/dependency_scanning/index.md) **(ULTIMATE)**          | Analyze your dependencies for known vulnerabilities.                   |
-| [Dynamic Application Security Testing (DAST)](user/application_security/dast/index.md) **(ULTIMATE)** | Analyze running web applications for known vulnerabilities.            |
-| [Group Security Dashboard](user/application_security/security_dashboard/index.md#group-security-dashboard) **(ULTIMATE)**      | View vulnerabilities in all the projects in a group and its subgroups. |
-| [Instance Security Dashboard](user/application_security/security_dashboard/index.md#instance-security-dashboard) **(ULTIMATE)**      | View vulnerabilities in all the projects you're interested in. |
-| [License Compliance](user/compliance/license_compliance/index.md) **(ULTIMATE)**            | Search your project's dependencies for their licenses.                 |
-| [Pipeline Security](user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**    | View the security reports for your project's pipelines.               |
-| [Project Security Dashboard](user/application_security/security_dashboard/index.md#project-security-dashboard) **(ULTIMATE)**    | View the latest security reports for your project.                     |
-| [Static Application Security Testing (SAST)](user/application_security/sast/index.md) **(ULTIMATE)**  | Analyze source code for known vulnerabilities.                         |
+| [Web Application Firewall with ModSecurity](user/compliance/compliance_dashboard/index.md) **(ULTIMATE)**  | Filter, monitor, and block HTTP traffic to and from a web application. |
+| [Container Host Security](user/clusters/applications.md#install-falco-using-gitlab-cicd)                   | Detect and respond to security threats at the Kubernetes, network, and host level. |
+| [Container Network Security](user/clusters/applications.md#install-cilium-using-gitlab-cicd)               |  Detect and block unauthorized network traffic between pods and to/from the internet.|
 
 ## New to Git and GitLab?
 
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index e10520aaf3d..6349a94eb0e 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -1,45 +1,50 @@
 ---
 reading_time: true
+stage: Enablement
+group: Distribution
+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/#designated-technical-writers
 ---
 
 # Reference architecture: up to 10,000 users
 
-This page describes GitLab reference architecture for up to 10,000 users.
-For a full list of reference architectures, see
+This page describes GitLab reference architecture for up to 10,000 users. For a
+full list of reference architectures, see
 [Available reference architectures](index.md#available-reference-architectures).
 
 > - **Supported users (approximate):** 10,000
-> - **High Availability:** True
-> - **Test RPS rates:** API: 200 RPS, Web: 20 RPS, Git: 20 RPS
-
-| Service                                                      | Nodes | Configuration                   | GCP              | AWS                   | Azure          |
-|--------------------------------------------------------------|-------|---------------------------------|------------------|-----------------------|----------------|
-| External load balancing node                                 | 1     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| Consul                                                       | 3     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| PostgreSQL                                                   | 3     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| PgBouncer                                                    | 3     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| Internal load balancing node                                 | 1     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| Redis - Cache                                                | 3     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| Redis - Queues / Shared State                                | 3     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| Redis Sentinel - Cache                                       | 3     | 1 vCPU, 1.7GB Memory            | `g1-small`       | `t2.small`            | `B1MS`         |
-| Redis Sentinel - Queues / Shared State                       | 3     | 1 vCPU, 1.7GB Memory            | `g1-small`       | `t2.small`            | `B1MS`         |
-| Gitaly                                                       | 2 minimum     | 16 vCPU, 60GB Memory    | `n1-standard-16` | `m5.4xlarge`          | `D16s v3`      |
-| Sidekiq                                                      | 4     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| GitLab Rails                                                 | 3     | 32 vCPU, 28.8GB Memory          | `n1-highcpu-32`  | `c5.9xlarge`          | `F32s v2`      |
-| Monitoring node                                              | 1     | 4 vCPU, 3.6GB Memory            | `n1-highcpu-4`   | `c5.xlarge`           | `F4s v2`       |
-| Object Storage                                               | n/a   | n/a                             | n/a              | n/a                   | n/a            |
-| NFS Server                                                   | 1     | 4 vCPU, 3.6GB Memory            | `n1-highcpu-4`   | `c5.xlarge`           | `F4s v2`       |
-
-The architectures were built and tested with the [Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
-CPU platform on GCP. On different hardware you may find that adjustments, either lower
-or higher, are required for your CPU or Node counts accordingly. For more information, a
-[Sysbench](https://github.com/akopytov/sysbench) benchmark of the CPU can be found
-[here](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).
-
-For data objects such as LFS, Uploads, Artifacts, etc., an [object storage service](#configure-the-object-storage)
-is recommended over NFS where possible, due to better performance and availability.
-Since this doesn't require a node to be set up, it's marked as not applicable (n/a)
-in the table above.
+> - **High Availability:** Yes
+> - **Test requests per second (RPS) rates:** API: 200 RPS, Web: 20 RPS, Git: 20 RPS
+
+| Service                                    | Nodes       | Configuration           | GCP             | AWS         | Azure    |
+|--------------------------------------------|-------------|-------------------------|-----------------|-------------|----------|
+| External load balancing node               | 1           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large    | F2s v2   |
+| Consul                                     | 3           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large    | F2s v2   |
+| PostgreSQL                                 | 3           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge   | D4s v3   |
+| PgBouncer                                  | 3           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large    | F2s v2   |
+| Internal load balancing node               | 1           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large    | F2s v2   |
+| Redis - Cache                              | 3           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge   | D4s v3   |
+| Redis - Queues / Shared State              | 3           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge   | D4s v3   |
+| Redis Sentinel - Cache                     | 3           | 1 vCPU, 1.7GB memory    | g1-small        | t2.small    | B1MS     |
+| Redis Sentinel - Queues / Shared State     | 3           | 1 vCPU, 1.7GB memory    | g1-small        | t2.small    | B1MS     |
+| Gitaly                                     | 2 (minimum) | 16 vCPU, 60GB memory    | n1-standard-16  | m5.4xlarge  | D16s v3  |
+| Sidekiq                                    | 4           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge   | D4s v3   |
+| GitLab Rails                               | 3           | 32 vCPU, 28.8GB memory  | n1-highcpu-32   | c5.9xlarge  | F32s v2  |
+| Monitoring node                            | 1           | 4 vCPU, 3.6GB memory    | n1-highcpu-4    | c5.xlarge   | F4s v2   |
+| Object Storage                             | n/a         | n/a                     | n/a             | n/a         | n/a      |
+| NFS Server                                 | 1           | 4 vCPU, 3.6GB memory    | n1-highcpu-4    | c5.xlarge   | F4s v2   |
+
+The Google Cloud Platform (GCP) architectures were built and tested using the
+[Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
+CPU platform. On different hardware you may find that adjustments, either lower
+or higher, are required for your CPU or node counts. For more information, see
+our [Sysbench](https://github.com/akopytov/sysbench)-based
+[CPU benchmark](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).
+
+For data objects (such as LFS, Uploads, or Artifacts), an
+[object storage service](#configure-the-object-storage) is recommended instead
+of NFS where possible, due to better performance and availability. Since this
+doesn't require a node to be set up, *Object Storage* is noted as not
+applicable (n/a) in the previous table.
 
 ## Setup components
 
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 23ca22e422a..0027cfcaf82 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -1,45 +1,50 @@
 ---
 reading_time: true
+stage: Enablement
+group: Distribution
+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/#designated-technical-writers
 ---
 
 # Reference architecture: up to 25,000 users
 
-This page describes GitLab reference architecture for up to 25,000 users.
-For a full list of reference architectures, see
+This page describes GitLab reference architecture for up to 25,000 users. For a
+full list of reference architectures, see
 [Available reference architectures](index.md#available-reference-architectures).
 
 > - **Supported users (approximate):** 25,000
-> - **High Availability:** True
-> - **Test RPS rates:** API: 500 RPS, Web: 50 RPS, Git: 50 RPS
-
-| Service                                                      | Nodes | Configuration                   | GCP              | AWS                   | Azure          |
-|--------------------------------------------------------------|-------|---------------------------------|------------------|-----------------------|----------------|
-| External load balancing node                                 | 1     | 4 vCPU, 3.6GB Memory            | `n1-highcpu-4`   | `c5.xlarge`           | `F4s v2`       |
-| Consul                                                       | 3     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| PostgreSQL                                                   | 3     | 8 vCPU, 30GB Memory             | `n1-standard-8`  | `m5.2xlarge`          | `D8s v3`       |
-| PgBouncer                                                    | 3     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| Internal load balancing node                                 | 1     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| Redis - Cache                                                | 3     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| Redis - Queues / Shared State                                | 3     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| Redis Sentinel - Cache                                       | 3     | 1 vCPU, 1.7GB Memory            | `g1-small`       | `t2.small`            | `B1MS`         |
-| Redis Sentinel - Queues / Shared State                       | 3     | 1 vCPU, 1.7GB Memory            | `g1-small`       | `t2.small`            | `B1MS`         |
-| Gitaly                                                       | 2 minimum     | 32 vCPU, 120GB Memory           | `n1-standard-32` | `m5.8xlarge`      | `D32s v3`        |
-| Sidekiq                                                      | 4     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| GitLab Rails                                                 | 5     | 32 vCPU, 28.8GB Memory          | `n1-highcpu-32`  | `c5.9xlarge`          | `F32s v2`      |
-| Monitoring node                                              | 1     | 4 vCPU, 3.6GB Memory            | `n1-highcpu-4`   | `c5.xlarge`           | `F4s v2`       |
-| Object Storage                                               | n/a   | n/a                             | n/a              | n/a                   | n/a            |
-| NFS Server                                                   | 1     | 4 vCPU, 3.6GB Memory            | `n1-highcpu-4`   | `c5.xlarge`           | `F4s v2`       |
-
-The architectures were built and tested with the [Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
-CPU platform on GCP. On different hardware you may find that adjustments, either lower
-or higher, are required for your CPU or Node counts accordingly. For more information, a
-[Sysbench](https://github.com/akopytov/sysbench) benchmark of the CPU can be found
-[here](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).
-
-For data objects such as LFS, Uploads, Artifacts, etc., an [object storage service](#configure-the-object-storage)
-is recommended over NFS where possible, due to better performance and availability.
-Since this doesn't require a node to be set up, it's marked as not applicable (n/a)
-in the table above.
+> - **High Availability:** Yes
+> - **Test requests per second (RPS) rates:** API: 500 RPS, Web: 50 RPS, Git: 50 RPS
+
+| Service                                 | Nodes       | Configuration           | GCP             | AWS         | Azure    |
+|-----------------------------------------|-------------|-------------------------|-----------------|-------------|----------|
+| External load balancing node            | 1           | 4 vCPU, 3.6GB memory    | n1-highcpu-4    | c5.xlarge   | F4s v2   |
+| Consul                                  | 3           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large    | F2s v2   |
+| PostgreSQL                              | 3           | 8 vCPU, 30GB memory     | n1-standard-8   | m5.2xlarge  | D8s v3   |
+| PgBouncer                               | 3           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large    | F2s v2   |
+| Internal load balancing node            | 1           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large    | F2s v2   |
+| Redis - Cache                           | 3           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge   | D4s v3   |
+| Redis - Queues / Shared State           | 3           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge   | D4s v3   |
+| Redis Sentinel - Cache                  | 3           | 1 vCPU, 1.7GB memory    | g1-small        | t2.small    | B1MS     |
+| Redis Sentinel - Queues / Shared State  | 3           | 1 vCPU, 1.7GB memory    | g1-small        | t2.small    | B1MS     |
+| Gitaly                                  | 2 (minimum) | 32 vCPU, 120GB memory   | n1-standard-32  | m5.8xlarge  | D32s v3  |
+| Sidekiq                                 | 4           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge   | D4s v3   |
+| GitLab Rails                            | 5           | 32 vCPU, 28.8GB memory  | n1-highcpu-32   | c5.9xlarge  | F32s v2  |
+| Monitoring node                         | 1           | 4 vCPU, 3.6GB memory    | n1-highcpu-4    | c5.xlarge   | F4s v2   |
+| Object Storage                          | n/a         | n/a                     | n/a             | n/a         | n/a      |
+| NFS Server                              | 1           | 4 vCPU, 3.6GB memory    | n1-highcpu-4    | c5.xlarge   | F4s v2   |
+
+The Google Cloud Platform (GCP) architectures were built and tested using the
+[Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
+CPU platform. On different hardware you may find that adjustments, either lower
+or higher, are required for your CPU or node counts. For more information, see
+our [Sysbench](https://github.com/akopytov/sysbench)-based
+[CPU benchmark](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).
+
+For data objects (such as LFS, Uploads, or Artifacts), an
+[object storage service](#configure-the-object-storage) is recommended instead
+of NFS where possible, due to better performance and availability. Since this
+doesn't require a node to be set up, *Object Storage* is noted as not
+applicable (n/a) in the previous table.
 
 ## Setup components
 
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 145ca4be7e0..e795acfaead 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -1,45 +1,50 @@
 ---
 reading_time: true
+stage: Enablement
+group: Distribution
+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/#designated-technical-writers
 ---
 
 # Reference architecture: up to 50,000 users
 
-This page describes GitLab reference architecture for up to 50,000 users.
-For a full list of reference architectures, see
+This page describes GitLab reference architecture for up to 50,000 users. For a
+full list of reference architectures, see
 [Available reference architectures](index.md#available-reference-architectures).
 
 > - **Supported users (approximate):** 50,000
-> - **High Availability:** True
-> - **Test RPS rates:** API: 1000 RPS, Web: 100 RPS, Git: 100 RPS
-
-| Service                                                      | Nodes | Configuration                   | GCP              | AWS                   | Azure          |
-|--------------------------------------------------------------|-------|---------------------------------|------------------|-----------------------|----------------|
-| External load balancing node                                 | 1     | 8 vCPU, 7.2GB Memory            | `n1-highcpu-8`   | `c5.2xlarge`          | `F8s v2`       |
-| Consul                                                       | 3     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| PostgreSQL                                                   | 3     | 16 vCPU, 60GB Memory            | `n1-standard-16` | `m5.4xlarge`          | `D16s v3`      |
-| PgBouncer                                                    | 3     | 2 vCPU, 1.8GB Memory            | `n1-highcpu-2`   | `c5.large`            | `F2s v2`       |
-| Internal load balancing node                                 | 1     | 8 vCPU, 7.2GB Memory            | `n1-highcpu-8`   | `c5.2xlarge`          | `F8s v2`       |
-| Redis - Cache                                                | 3     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| Redis - Queues / Shared State                                | 3     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| Redis Sentinel - Cache                                       | 3     | 1 vCPU, 1.7GB Memory            | `g1-small`       | `t2.small`            | `B1MS`         |
-| Redis Sentinel - Queues / Shared State                       | 3     | 1 vCPU, 1.7GB Memory            | `g1-small`       | `t2.small`            | `B1MS`         |
-| Gitaly                                                       | 2 minimum     | 64 vCPU, 240GB Memory   | `n1-standard-64` | `m5.16xlarge`         | `D64s v3`      |
-| Sidekiq                                                      | 4     | 4 vCPU, 15GB Memory             | `n1-standard-4`  | `m5.xlarge`           | `D4s v3`       |
-| GitLab Rails                                                 | 12    | 32 vCPU, 28.8GB Memory          | `n1-highcpu-32`  | `c5.9xlarge`          | `F32s v2`      |
-| Monitoring node                                              | 1     | 4 vCPU, 3.6GB Memory            | `n1-highcpu-4`   | `c5.xlarge`           | `F4s v2`       |
-| Object Storage                                               | n/a   | n/a                             | n/a              | n/a                   | n/a            |
-| NFS Server                                                   | 1     | 4 vCPU, 3.6GB Memory            | `n1-highcpu-4`   | `c5.xlarge`           | `F4s v2`       |
-
-The architectures were built and tested with the [Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
-CPU platform on GCP. On different hardware you may find that adjustments, either lower
-or higher, are required for your CPU or Node counts accordingly. For more information, a
-[Sysbench](https://github.com/akopytov/sysbench) benchmark of the CPU can be found
-[here](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).
-
-For data objects such as LFS, Uploads, Artifacts, etc., an [object storage service](#configure-the-object-storage)
-is recommended over NFS where possible, due to better performance and availability.
-Since this doesn't require a node to be set up, it's marked as not applicable (n/a)
-in the table above.
+> - **High Availability:** Yes
+> - **Test requests per second (RPS) rates:** API: 1000 RPS, Web: 100 RPS, Git: 100 RPS
+
+| Service                                 | Nodes       | Configuration           | GCP             | AWS          | Azure    |
+|-----------------------------------------|-------------|-------------------------|-----------------|--------------|----------|
+| External load balancing node            | 1           | 8 vCPU, 7.2GB memory    | n1-highcpu-8    | c5.2xlarge   | F8s v2   |
+| Consul                                  | 3           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large     | F2s v2   |
+| PostgreSQL                              | 3           | 16 vCPU, 60GB memory    | n1-standard-16  | m5.4xlarge   | D16s v3  |
+| PgBouncer                               | 3           | 2 vCPU, 1.8GB memory    | n1-highcpu-2    | c5.large     | F2s v2   |
+| Internal load balancing node            | 1           | 8 vCPU, 7.2GB memory    | n1-highcpu-8    | c5.2xlarge   | F8s v2   |
+| Redis - Cache                           | 3           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge    | D4s v3   |
+| Redis - Queues / Shared State           | 3           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge    | D4s v3   |
+| Redis Sentinel - Cache                  | 3           | 1 vCPU, 1.7GB memory    | g1-small        | t2.small     | B1MS     |
+| Redis Sentinel - Queues / Shared State  | 3           | 1 vCPU, 1.7GB memory    | g1-small        | t2.small     | B1MS     |
+| Gitaly                                  | 2 (minimum) | 64 vCPU, 240GB memory   | n1-standard-64  | m5.16xlarge  | D64s v3  |
+| Sidekiq                                 | 4           | 4 vCPU, 15GB memory     | n1-standard-4   | m5.xlarge    | D4s v3   |
+| GitLab Rails                            | 12          | 32 vCPU, 28.8GB memory  | n1-highcpu-32   | c5.9xlarge   | F32s v2  |
+| Monitoring node                         | 1           | 4 vCPU, 3.6GB memory    | n1-highcpu-4    | c5.xlarge    | F4s v2   |
+| Object Storage                          | n/a         | n/a                     | n/a             | n/a          | n/a      |
+| NFS Server                              | 1           | 4 vCPU, 3.6GB memory    | n1-highcpu-4    | c5.xlarge    | F4s v2   |
+
+The Google Cloud Platform (GCP) architectures were built and tested using the
+[Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
+CPU platform. On different hardware you may find that adjustments, either lower
+or higher, are required for your CPU or node counts. For more information, see
+our [Sysbench](https://github.com/akopytov/sysbench)-based
+[CPU benchmark](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).
+
+For data objects (such as LFS, Uploads, or Artifacts), an
+[object storage service](#configure-the-object-storage) is recommended instead
+of NFS where possible, due to better performance and availability. Since this
+doesn't require a node to be set up, *Object Storage* is noted as not
+applicable (n/a) in the previous table.
 
 ## Setup components
 
diff --git a/doc/img/devops-stages-13_3.png b/doc/img/devops-stages-13_3.png
new file mode 100644
index 00000000000..fe4def8d075
--- /dev/null
+++ b/doc/img/devops-stages-13_3.png
diff --git a/doc/img/devops-stages.png b/doc/img/devops-stages.png
deleted file mode 100644
index 2fa5357062c..00000000000
--- a/doc/img/devops-stages.png
+++ /dev/null
diff --git a/doc/operations/feature_flags.md b/doc/operations/feature_flags.md
index 8348f8e6295..46a57e72484 100644
--- a/doc/operations/feature_flags.md
+++ b/doc/operations/feature_flags.md
@@ -140,6 +140,14 @@ Enables the feature for lists of users created [in the Feature Flags UI](#create
 Similar to [User IDs](#user-ids), it uses the Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid)
 activation strategy.
 
+It's not possible to *disable* a feature for members of a user list, but you can achieve the same
+effect by enabling a feature for a user list that doesn't contain the excluded users.
+
+For example:
+
+- `Full-user-list` = `User1A, User1B, User2A, User2B, User3A, User3B, ...`
+- `Full-user-list-excluding-B-users` = `User1A, User2A, User3A, ...`
+
 #### Create a user list
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13308) in GitLab 13.3.
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index d68928d858b..0b52aa6e468 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -608,8 +608,11 @@ Alternatively, you can use the variable `SECURE_ANALYZERS_PREFIX` to override th
 > - It's able to be enabled or disabled per-project.
 > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-on-demand-scans).
 
-Passive DAST scans may be run on demand against a target website, outside the DevOps lifecycle. These scans will
-always be associated with the default or `master` branch of your project and the results can be seen in the project dashboard.
+Passive DAST scans may be run on demand against a target website, outside the DevOps lifecycle. These scans are
+always associated with the default or `master` branch of your project and the results can be seen in the project dashboard.
+
+NOTE: **Note:**
+You cannot run an on-demand DAST scan against a protected branch unless you have permission to do so. The `master` branch is protected by default. For more details, see [Pipeline security on protected branches](../../../ci/pipelines/index.md#pipeline-security-on-protected-branches).
 
 ![DAST On-Demand Scan](img/dast_on_demand_v13_2.png)
 
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index ce9d366811c..5b92f146e4b 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -1,7 +1,8 @@
 # Design Management
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/660) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.2.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212566) to GitLab Core in 13.0.
+> - Support for SVGs was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12771) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
+> - Design Management was [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212566) to GitLab Core in 13.0.
 
 ## Overview
 
@@ -41,10 +42,9 @@ If the requirements are not met, the **Designs** tab displays a message to the u
 ## Supported files
 
 Files uploaded must have a file extension of either `png`, `jpg`, `jpeg`,
-`gif`, `bmp`, `tiff` or `ico`.
+`gif`, `bmp`, `tiff`, `ico`, or `svg`.
 
-Support for [SVG files](https://gitlab.com/gitlab-org/gitlab/-/issues/12771)
-and [PDFs](https://gitlab.com/gitlab-org/gitlab/-/issues/32811) is planned for a future release.
+Support for [PDF](https://gitlab.com/gitlab-org/gitlab/issues/32811) is planned for a future release.
 
 ## Limitations
 
diff --git a/doc/user/search/advanced_global_search.md b/doc/user/search/advanced_global_search.md
index c8ef1d9e5af..820d66e4cd6 100644
--- a/doc/user/search/advanced_global_search.md
+++ b/doc/user/search/advanced_global_search.md
@@ -22,20 +22,20 @@ visit the [administrator documentation](../../integration/elasticsearch.md).
 
 The Advanced Global Search in GitLab is a powerful search service that saves
 you time. Instead of creating duplicate code and wasting time, you can
-now search for code within other teams that can help your own project.
+now search for code within other projects that can help your own project.
 
 GitLab leverages the search capabilities of [Elasticsearch](https://www.elastic.co/elasticsearch/) and enables it when
 searching in:
 
 - Projects
-- Repositories
-- Commits
 - Issues
 - Merge requests
 - Milestones
-- Notes (comments)
-- Snippets
+- Comments
+- Code
+- Commits
 - Wiki
+- Users
 
 ## Use cases