Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42

6 files changed, 33 insertions, 7 deletions

diff --git a/doc/user/infrastructure/clusters/connect/img/variables_civo.png b/doc/user/infrastructure/clusters/connect/img/variables_civo.png
index 5a20478b13c..a668c3dd53c 100644
--- a/doc/user/infrastructure/clusters/connect/img/variables_civo.png
+++ b/doc/user/infrastructure/clusters/connect/img/variables_civo.png
diff --git a/doc/user/infrastructure/clusters/connect/new_civo_cluster.md b/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
index d8401d5a286..fad75ca6cab 100644
--- a/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
+++ b/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
@@ -64,7 +64,7 @@ Use CI/CD environment variables to configure your project.
 
 1. On the left sidebar, select **Settings > CI/CD**.
 1. Expand **Variables**.
-1. Set the variable `BASE64_CIVO_CREDENTIALS` to the [token](https://www.civo.com/account/security) from your Civo account.
+1. Set the variable `BASE64_CIVO_TOKEN` to the [token](https://www.civo.com/account/security) from your Civo account.
 1. Set the variable `TF_VAR_agent_token` to the agent token you received in the previous task.
 1. Set the variable `TF_VAR_kas_address` to the agent server address in the previous task.
 
@@ -78,8 +78,8 @@ contains other variables that you can override according to your needs:
 - `TF_VAR_civo_region`: Set your cluster's region.
 - `TF_VAR_cluster_name`: Set your cluster's name.
 - `TF_VAR_cluster_description`: Set a description for the cluster. To create a reference to your GitLab project on your Civo cluster detail page, set this value to `$CI_PROJECT_URL`. This value helps you determine which project was responsible for provisioning the cluster you see on the Civo dashboard.
-- `TF_VAR_machine_type`: Set the machine type for the Kubernetes nodes.
-- `TF_VAR_node_count`: Set the number of Kubernetes nodes.
+- `TF_VAR_target_nodes_size`: Set the size of the nodes to use for the cluster
+- `TF_VAR_num_target_nodes`: Set the number of Kubernetes nodes.
 - `TF_VAR_agent_version`: Set the version of the GitLab agent.
 - `TF_VAR_agent_namespace`: Set the Kubernetes namespace for the GitLab agent.
 
diff --git a/doc/user/infrastructure/clusters/index.md b/doc/user/infrastructure/clusters/index.md
index 933b310ff3f..9c8bcd9289c 100644
--- a/doc/user/infrastructure/clusters/index.md
+++ b/doc/user/infrastructure/clusters/index.md
@@ -13,7 +13,10 @@ To connect clusters to GitLab, use the [GitLab agent](../../clusters/agent/index
 WARNING:
 In GitLab 14.5, the certificate-based method to connect Kubernetes clusters
 to GitLab was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8),
-as well as its related [features](#deprecated-features).
+as well as its related [features](#deprecated-features). In self-managed GitLab 15.0 and later,
+this feature is disabled by default. For GitLab SaaS users, this feature is available until
+GitLab 15.6 for users who have at least one certificate-based cluster enabled in their namespace hierarchy.
+For GitLab SaaS users that never used this feature previously, it is no longer available.
 
 The certificate-based Kubernetes integration with GitLab is deprecated.
 It had the following issues:
@@ -40,6 +43,10 @@ for updates.
 You can find technical information about why we moved away from cluster certificates into
 the GitLab agent model on the [agent's blueprint documentation](../../../architecture/blueprints/gitlab_to_kubernetes_communication/index.md).
 
+If you need more time to migrate to GitLab agent, you can [enable the feature flag](../../../administration/feature_flags.md)
+named `certificate_based_clusters`, which was [introduced in GitLab 15.0](../../../update/deprecations.md#self-managed-certificate-based-integration-with-kubernetes).
+This feature flag re-enables the certificate-based Kubernetes integration.
+
 ## Deprecated features
 
 - [Connect an existing cluster through cluster certificates](../../project/clusters/add_existing_cluster.md)
@@ -52,7 +59,6 @@ the GitLab agent model on the [agent's blueprint documentation](../../../archite
 - [Cluster environments](../../clusters/environments.md)
 - [Show Canary Ingress deployments on deploy boards](../../project/canary_deployments.md#show-canary-ingress-deployments-on-deploy-boards-deprecated)
 - [Deploy Boards](../../project/deploy_boards.md)
-- [Pod logs](../../project/clusters/kubernetes_pod_logs.md)
 - [Clusters health](manage/clusters_health.md)
 - [Web terminals](../../../administration/integration/terminal.md)
 
diff --git a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
index aa07a23db18..abdb7c58d82 100644
--- a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
+++ b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
@@ -40,7 +40,7 @@ Some features are currently available only when using certificate-based integrat
 With GitLab-managed clusters, GitLab creates separate service accounts and namespaces
 for every branch and deploys by using these resources.
 
-The GitLab agent uses [impersonation](../../clusters/agent/ci_cd_workflow.md#use-impersonation-to-restrict-project-and-group-access)
+The GitLab agent uses [impersonation](../../clusters/agent/ci_cd_workflow.md#restrict-project-and-group-access-by-using-impersonation)
 strategies to deploy to your cluster with restricted account access. To do so:
 
 1. Choose the impersonation strategy that suits your needs.
diff --git a/doc/user/infrastructure/iac/terraform_state.md b/doc/user/infrastructure/iac/terraform_state.md
index e8637abce91..24203e8d922 100644
--- a/doc/user/infrastructure/iac/terraform_state.md
+++ b/doc/user/infrastructure/iac/terraform_state.md
@@ -22,6 +22,16 @@ In GitLab, you can:
 - Lock and unlock states.
 - Remotely execute `terraform plan` and `terraform apply` commands.
 
+WARNING:
+**Disaster recovery planning**
+Terraform state files are encrypted with the lockbox Ruby gem when they are at rest on disk and in object storage.
+[To decrypt a state file, GitLab must be available](https://gitlab.com/gitlab-org/gitlab/-/issues/335739).
+If it is offline, and you use GitLab to deploy infrastructure that GitLab requires (like virtual machines,
+Kubernetes clusters, or network components), you cannot access the state file easily or decrypt it.
+Additionally, if GitLab serves up Terraform modules or other dependencies that are required to bootstrap GitLab,
+these will be inaccessible. To work around this issue, make other arrangements to host or back up these dependencies,
+or consider using a separate GitLab instance with no shared points of failure.
+
 ## Prerequisites
 
 For self-managed GitLab, before you can use GitLab for your Terraform state files:
@@ -151,7 +161,8 @@ You can use a GitLab-managed Terraform state backend as a
      a [Personal Access Token](../../profile/personal_access_tokens.md) for
      authentication, this value is your GitLab username. If you are using GitLab CI/CD, this value is `'gitlab-ci-token'`.
    - **password**: The password to authenticate with the data source. If you are using a Personal Access Token for
-     authentication, this value is the token value. If you are using GitLab CI/CD, this value is the contents of the `${CI_JOB_TOKEN}` CI/CD variable.
+     authentication, this value is the token value (the token must have the **API** scope).
+     If you are using GitLab CI/CD, this value is the contents of the `${CI_JOB_TOKEN}` CI/CD variable.
 
 Outputs from the data source can now be referenced in your Terraform resources
 using `data.terraform_remote_state.example.outputs.<OUTPUT-NAME>`.
diff --git a/doc/user/infrastructure/iac/troubleshooting.md b/doc/user/infrastructure/iac/troubleshooting.md
index 881bcb32aed..5817337223f 100644
--- a/doc/user/infrastructure/iac/troubleshooting.md
+++ b/doc/user/infrastructure/iac/troubleshooting.md
@@ -112,3 +112,12 @@ job that returned the error:
 
 1. Configure the [CI/CD environment scope](../../../ci/variables/#add-a-cicd-variable-to-a-project) for the job.
 1. Set the job's [environment](../../../ci/yaml/#environment), matching the environment scope from the previous step.
+
+### Error refreshing state: HTTP remote state endpoint requires auth
+
+To resolve this, ensure that:
+
+- The access token you use has `api` scope.
+- If you have set the `TF_HTTP_PASSWORD` CI/CD variable, make sure that you either:
+  - Set the same value as `TF_PASSWORD`
+  - Remove `TF_HTTP_PASSWORD` variable if your CI/CD job does not explicitly use it.