Add latest changes from gitlab-org/gitlab@master

7 files changed, 184 insertions, 87 deletions

diff --git a/doc/user/admin_area/settings/package_registry_rate_limits.md b/doc/user/admin_area/settings/package_registry_rate_limits.md
index 6e7b9b0da30..1aeb011d880 100644
--- a/doc/user/admin_area/settings/package_registry_rate_limits.md
+++ b/doc/user/admin_area/settings/package_registry_rate_limits.md
@@ -7,28 +7,47 @@ type: reference
 
 # Package Registry Rate Limits **(FREE SELF)**
 
-Rate limiting is a common technique used to improve the security and durability of a web
-application. For more details, see [Rate limits](../../../security/rate_limits.md). General user and
-IP rate limits can be enforced from the top bar at
-**Menu > Admin > Settings > Network > User and IP rate limits**.
-For more details, see [User and IP rate limits](user_and_ip_rate_limits.md).
-
 With the [GitLab Package Registry](../../packages/package_registry/index.md),
 you can use GitLab as a private or public registry for a variety of common package managers. You can
 publish and share packages, which others can consume as a dependency in downstream projects through
 the [Packages API](../../../api/packages.md).
 
-When downloading such dependencies in downstream projects, many requests are made through the
-Packages API. You may therefore reach enforced user and IP rate limits. To address this issue, you
-can define specific rate limits for the Packages API in
-**Menu > Admin > Settings > Network > Package Registry Rate Limits**:
+If downstream projects frequently download such dependencies, many requests are made through the
+Packages API. You may therefore reach enforced [user and IP rate limits](user_and_ip_rate_limits.md).
+To address this issue, you can define specific rate limits for the Packages API:
+
+- [Unauthenticated requests (per IP)](#enable-unauthenticated-request-rate-limit-for-packages-api).
+- [Authenticated API requests (per user)](#enable-authenticated-api-request-rate-limit-for-packages-api).
+
+These limits are disabled by default.
+
+When enabled, they supersede the general user and IP rate limits for requests to
+the Packages API. You can therefore keep the general user and IP rate limits, and
+increase the rate limits for the Packages API. Besides this precedence, there is
+no difference in functionality compared to the general user and IP rate limits.
+
+## Enable unauthenticated request rate limit for packages API
+
+To enable the unauthenticated request rate limit:
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Settings > Network**, and expand **Package registry rate limits**.
+1. Select **Enable unauthenticated request rate limit**.
+
+   - Optional. Update the **Maximum unauthenticated requests per rate limit period per IP** value.
+     Defaults to `800`.
+   - Optional. Update the **Unauthenticated rate limit period in seconds** value.
+     Defaults to `15`.
+
+## Enable authenticated API request rate limit for packages API
 
-- Unauthenticated Packages API requests
-- Authenticated Packages API requests
+To enable the authenticated API request rate limit:
 
-These limits are disabled by default. When enabled, they supersede the general user and IP rate
-limits for requests to the Packages API. You can therefore keep the general user and IP rate limits,
-and increase (if necessary) the rate limits for the Packages API.
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Settings > Network**, and expand **Package registry rate limits**.
+1. Select **Enable authenticated API request rate limit**.
 
-Besides this precedence, there are no differences in functionality compared to the general user and
-IP rate limits. For more details, see [User and IP rate limits](user_and_ip_rate_limits.md).
+   - Optional. Update the **Maximum authenticated API requests per rate limit period per user** value.
+     Defaults to `1000`.
+   - Optional. Update the **Authenticated API rate limit period in seconds** value.
+     Defaults to `15`.
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 15cd6e4a75f..5c409233e5f 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -1145,6 +1145,21 @@ The site is validated and an active scan can run against it.
 
 If a validated site profile's target URL is edited, the site's validation status is revoked.
 
+#### Retry a failed validation
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322609) in GitLab 14.3.
+
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an
+administrator to [disable the `dast_failed_site_validations` flag](../../../administration/feature_flags.md).
+
+If a site profile's validation fails, you can retry it by selecting the **Retry validation** button
+in the profiles list.
+
+When loading the DAST profiles library, past failed validations are listed above the profiles
+list. You can also retry the validation from there by selecting the **Retry validation** link in
+the alert. You can also dismiss the alert to revoke failed validations.
+
 #### Revoke a site profile's validation status
 
 Note that all site profiles with the same URL have their validation status revoked.
diff --git a/doc/user/infrastructure/clusters/connect/index.md b/doc/user/infrastructure/clusters/connect/index.md
new file mode 100644
index 00000000000..ada278292a9
--- /dev/null
+++ b/doc/user/infrastructure/clusters/connect/index.md
@@ -0,0 +1,126 @@
+---
+stage: Configure
+group: Configure
+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
+---
+
+# Connect a cluster to GitLab **(FREE)**
+
+You can create new or connect existing clusters to GitLab through different [levels](#cluster-levels),
+using different [methods](#methods-to-connect-a-cluster-to-gitlab).
+
+Before getting started:
+
+1. Check the [supported Kubernetes cluster versions](#supported-cluster-versions).
+1. Define the [cluster level](#cluster-levels) according to your case.
+
+After that:
+
+1. Choose the [method](#methods-to-connect-a-cluster-to-gitlab)
+to connect your cluster according to your case.
+1. [View your clusters](#view-your-clusters) connected to GitLab.
+
+## Methods to connect a cluster to GitLab
+
+GitLab offers three methods to connect existing and create new clusters:
+
+- **GitLab Kubernetes Agent**: the best solution to
+[connect existing clusters](#connect-existing-clusters-to-gitlab).
+- **Infrastructure as Code**: it's a broader infrastructure management
+toolset that includes managing your cluster. It's the recommended
+solution to [create a new cluster](#create-new-clusters-from-gitlab)
+from GitLab.
+- **Certificate-based method**: our first and legacy solution uses
+cluster certificates to connect your cluster to GitLab. It is no longer
+recommended for [security implications](#security-implications-for-clusters-connected-with-certificates).
+
+### Connect existing clusters to GitLab
+
+To safely connect and configure an existing cluster on the **project level**,
+we **recommend** using the [GitLab Kubernetes Agent](../../../clusters/agent/index.md).
+We are working to support [the Agent for connecting a cluster at the group level](https://gitlab.com/groups/gitlab-org/-/epics/5784).
+
+Alternatively, you can use [cluster certificates](../../../project/clusters/add_existing_cluster.md)
+to connect clusters in all levels (projects, group, instance). However,
+for [security implications](#security-implications-for-clusters-connected-with-certificates),
+we don't recommend using this method.
+
+### Create new clusters from GitLab
+
+To safely create new clusters from GitLab, use
+[Infrastructure as Code](../../iac/index.md#create-a-new-cluster-through-iac).
+
+The [certificate-based method to create a new cluster](../../../project/clusters/add_remove_clusters.md)
+is still available through the GitLab UI but was **deprecated** in GitLab 14.0.
+If possible, we don't recommend using this method.
+
+### Connect multiple clusters to a single project
+
+To connect multiple clusters to a single project in GitLab,
+we **recommend** using the [GitLab Kubernetes Agent](../../../clusters/agent/index.md).
+
+You can also use the [certificate-based method](../../../project/clusters/multiple_kubernetes_clusters.md),
+but, for [security implications](#security-implications-for-clusters-connected-with-certificates),
+we don't recommend using this method.
+
+## Cluster levels
+
+Choose your cluster's level according to its purpose:
+
+| Level | Purpose |
+|--|--|
+| [Project level](../../../project/clusters/index.md) | Use your cluster for a single project. |
+| [Group level](../../../group/clusters/index.md) | Use the same cluster across multiple projects within your group. |
+| [Instance level](../../../instance/clusters/index.md) **(FREE SELF)** | Use the same cluster across groups and projects within your instance. |
+
+## Supported cluster versions
+
+GitLab is committed to support at least two production-ready Kubernetes minor
+versions at any given time. We regularly review the versions we support, and
+provide a three-month deprecation period before we remove support of a specific
+version. The range of supported versions is based on the evaluation of:
+
+- The versions supported by major managed Kubernetes providers.
+- The versions [supported by the Kubernetes community](https://kubernetes.io/releases/version-skew-policy/#supported-versions).
+
+GitLab supports the following Kubernetes versions, and you can upgrade your
+Kubernetes version to any supported version at any time:
+
+- 1.19 (support ends on February 22, 2022)
+- 1.18 (support ends on November 22, 2021)
+- 1.17 (support ends on September 22, 2021)
+
+Some GitLab features may support versions outside the range provided here.
+
+## View your clusters
+
+To view the Kubernetes clusters connected to your project,
+group, or instance, open the cluster's page according to the
+[level](#cluster-levels) of your cluster.
+
+**Project-level clusters:**
+
+1. Go to your project's homepage.
+1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+
+**Group-level clusters:**
+
+1. Go to your group's homepage.
+1. On the left sidebar, select **Kubernetes**.
+
+**Instance-level clusters:** **(FREE SELF)**
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Kubernetes**.
+
+## Security implications for clusters connected with certificates
+
+WARNING:
+The whole cluster security is based on a model where [developers](../../../permissions.md)
+are trusted, so **only trusted users should be allowed to control your clusters**.
+
+The use of cluster certificates to connect your cluster grants
+access to a wide set of functionalities needed to successfully
+build and deploy a containerized application. Bear in mind that
+the same credentials are used for all the applications running
+on the cluster.
diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md
index 8b171a4b04b..e92a6d6a162 100644
--- a/doc/user/project/clusters/add_eks_clusters.md
+++ b/doc/user/project/clusters/add_eks_clusters.md
@@ -166,7 +166,7 @@ When you create a new cluster, you have the following settings:
 | Kubernetes cluster name | Your cluster's name. |
 | Environment scope       | The [associated environment](multiple_kubernetes_clusters.md#setting-the-environment-scope). |
 | Service role            | The **EKS IAM role** (**role A**). |
-| Kubernetes version      | The [Kubernetes version](index.md#supported-cluster-versions) for your cluster. |
+| Kubernetes version      | The [Kubernetes version](../../infrastructure/clusters/connect/index.md#supported-cluster-versions) for your cluster. |
 | Key pair name           | The [key pair](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) that you can use to connect to your worker nodes. |
 | VPC                     | The [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) to use for your EKS Cluster resources. |
 | Subnets                 | The [subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html) in your VPC where your worker nodes run. Two are required. |
diff --git a/doc/user/project/clusters/add_existing_cluster.md b/doc/user/project/clusters/add_existing_cluster.md
index 16f66081e99..505c493de4e 100644
--- a/doc/user/project/clusters/add_existing_cluster.md
+++ b/doc/user/project/clusters/add_existing_cluster.md
@@ -217,7 +217,8 @@ integration to work properly.
 WARNING:
 Disabling RBAC means that any application running in the cluster,
 or user who can authenticate to the cluster, has full API access. This is a
-[security concern](index.md#security-implications), and may not be desirable.
+[security concern](../../infrastructure/clusters/connect/index.md#security-implications-for-clusters-connected-with-certificates),
+and may not be desirable.
 
 To effectively disable RBAC, global permissions can be applied granting full access:
 
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index a7f010b7852..0484121db62 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -54,7 +54,7 @@ As of GitLab 14.0, use the [GitLab Kubernetes Agent](../../clusters/agent/index.
 to connect your cluster to GitLab.
 
 Alternativelly, you can [add an existing cluster](add_existing_cluster.md)
-through the certificate-based method, but we don't recommend using this method for [security implications](index.md#security-implications).
+through the certificate-based method, but we don't recommend using this method for [security implications](../../infrastructure/clusters/connect/index.md#security-implications-for-clusters-connected-with-certificates).
 
 ## Configure your cluster
 
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index a5ac41b3837..791dc90cad5 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -33,75 +33,11 @@ features such as:
 
 ## Supported cluster versions
 
-GitLab is committed to support at least two production-ready Kubernetes minor
-versions at any given time. We regularly review the versions we support, and
-provide a three-month deprecation period before we remove support of a specific
-version. The range of supported versions is based on the evaluation of:
+See the [Kubernetes clusters versions supported by GitLab](../../infrastructure/clusters/connect/index.md#supported-cluster-versions).
 
-- The versions supported by major managed Kubernetes providers.
-- The versions [supported by the Kubernetes community](https://kubernetes.io/releases/version-skew-policy/#supported-versions).
+## Connect your cluster to GitLab
 
-GitLab supports the following Kubernetes versions, and you can upgrade your
-Kubernetes version to any supported version at any time:
-
-- 1.20 (support ends on April 22, 2022)
-- 1.19 (support ends on February 22, 2022)
-- 1.18 (support ends on November 22, 2021)
-- 1.17 (support ends on September 22, 2021)
-
-Some GitLab features may support versions outside the range provided here.
-
-## Add and remove clusters
-
-You can create new or add existing clusters to GitLab through different [levels](#cluster-levels),
-using different methods.
-
-### Methods to connect existing clusters
-
-To safely connect and configure an existing cluster on the **project level**, we
-**recommend** using the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
-We are working to support [the Agent for connecting a
-cluster at the group level](https://gitlab.com/groups/gitlab-org/-/epics/5784).
-
-You can use [cluster certificates](add_existing_cluster.md) to connect
-clusters in all levels (projects, group, instance). However, for
-[security implications](#security-implications), this method is no longer recommended.
-
-To create new clusters, we **recommend** using
-[Infrastructure as Code](../../infrastructure/iac/index.md#create-a-new-cluster-through-iac).
-
-### Cluster levels
-
-You can connect clusters to GitLab in different levels, according to their purpose:
-
-- On the project level, to have a cluster dedicated to a project.
-- On the [group level](../../group/clusters/index.md), to use the same cluster across multiple projects within your group.
-- On the [instance level](../../instance/clusters/index.md), to use the same cluster across multiple groups and projects. **(FREE SELF)**
-
-## Security implications
-
-WARNING:
-The whole cluster security is based on a model where [developers](../../permissions.md)
-are trusted, so **only trusted users should be allowed to control your clusters**.
-
-The default cluster configuration grants access to a wide set of
-functionalities needed to successfully build and deploy a containerized
-application. Bear in mind that the same credentials are used for all the
-applications running on the cluster.
-
-## View your clusters
-
-To view your project-level Kubernetes clusters, to go **Infrastructure > Kubernetes clusters**
-from your project. On this page, you can add a new cluster
-and view information about your existing clusters, such as:
-
-- Nodes count.
-- Rough estimates of memory and CPU usage.
-
-## Multiple Kubernetes clusters
-
-See how to associate [multiple Kubernetes clusters](multiple_kubernetes_clusters.md)
-with your GitLab project.
+Learn how to [create new and connect existing clusters to GitLab](../../infrastructure/clusters/connect/index.md).
 
 ## Cluster integrations