From 6e2dde590e694c13efdd441e058a925dcff17258 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Wed, 15 Sep 2021 15:10:13 +0000 Subject: Add latest changes from gitlab-org/gitlab@master --- .../settings/package_registry_rate_limits.md | 53 ++++++--- doc/user/application_security/dast/index.md | 15 +++ doc/user/infrastructure/clusters/connect/index.md | 126 +++++++++++++++++++++ doc/user/project/clusters/add_eks_clusters.md | 2 +- doc/user/project/clusters/add_existing_cluster.md | 3 +- doc/user/project/clusters/add_remove_clusters.md | 2 +- doc/user/project/clusters/index.md | 70 +----------- 7 files changed, 184 insertions(+), 87 deletions(-) create mode 100644 doc/user/infrastructure/clusters/connect/index.md (limited to 'doc/user') 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 -- cgit v1.2.3