Add latest changes from gitlab-org/gitlab@15-0-stable-eev15.0.0-rc42

15 files changed, 67 insertions, 332 deletions

diff --git a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
index ab04187284d..be58b4565a1 100644
--- a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
+++ b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
@@ -97,6 +97,8 @@ Use CI/CD environment variables to configure your project.
 1. Expand **Variables**.
 1. Set the variable `BASE64_GOOGLE_CREDENTIALS` to the `base64` encoded JSON file you just created.
 1. Set the variable `TF_VAR_gcp_project` to your GCP's `project` name.
+1. Set the variable `TF_VAR_agent_token` to the agent token displayed in the previous task.
+1. Set the variable `TF_VAR_kas_address` to the agent server address displayed in the previous task. 
 
 **Optional configuration:**
 
diff --git a/doc/user/infrastructure/clusters/index.md b/doc/user/infrastructure/clusters/index.md
index cd7c5feb284..933b310ff3f 100644
--- a/doc/user/infrastructure/clusters/index.md
+++ b/doc/user/infrastructure/clusters/index.md
@@ -18,7 +18,7 @@ as well as its related [features](#deprecated-features).
 The certificate-based Kubernetes integration with GitLab is deprecated.
 It had the following issues:
 
-- There were security issues as it required direct access to the Kube API by GitLab.
+- There were security issues as it required direct access to the Kubernetes API by GitLab.
 - The configuration options weren't flexible.
 - The integration was flaky.
 - Users were constantly reporting issues with features based on this model.
@@ -42,22 +42,18 @@ the GitLab agent model on the [agent's blueprint documentation](../../../archite
 
 ## Deprecated features
 
-- [Create a new cluster through cluster certificates](../../project/clusters/add_remove_clusters.md)
 - [Connect an existing cluster through cluster certificates](../../project/clusters/add_existing_cluster.md)
 - [Access controls](../../project/clusters/cluster_access.md)
 - [GitLab-managed clusters](../../project/clusters/gitlab_managed_clusters.md)
-- [GitLab Managed Apps](../../clusters/applications.md)
 - [Deploy applications through certificate-based connection](../../project/clusters/deploy_to_cluster.md)
 - [Cluster Management Project](../../clusters/management_project.md)
 - [Cluster integrations](../../clusters/integrations.md)
 - [Cluster cost management](../../clusters/cost_management.md)
 - [Cluster environments](../../clusters/environments.md)
-- [Advanced traffic control with Canary Ingress](../../project/canary_deployments.md#advanced-traffic-control-with-canary-ingress-deprecated)
-- [Serverless](../../project/clusters/serverless/index.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)
-- [Crossplane integration](../../clusters/crossplane.md)
 - [Web terminals](../../../administration/integration/terminal.md)
 
 ### Cluster levels
@@ -67,5 +63,5 @@ The concept of [project-level](../../project/clusters/index.md),
 [instance-level](../../instance/clusters/index.md) clusters becomes
 extinct in the new model, although the functionality remains to some extent.
 
-The agent is always configured in a single GitLab project and you can expose the cluster connection to other projects and groups to [access it from GitLab CI/CD](../../clusters/agent/ci_cd_tunnel.md).
+The agent is always configured in a single GitLab project and you can expose the cluster connection to other projects and groups to [access it from GitLab CI/CD](../../clusters/agent/ci_cd_workflow.md).
 By doing so, you are granting these projects and groups access to the same cluster, which is similar to group-level clusters' use case.
diff --git a/doc/user/infrastructure/clusters/manage/clusters_health.md b/doc/user/infrastructure/clusters/manage/clusters_health.md
index eeb931f392f..0eefae3f550 100644
--- a/doc/user/infrastructure/clusters/manage/clusters_health.md
+++ b/doc/user/infrastructure/clusters/manage/clusters_health.md
@@ -4,10 +4,15 @@ 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
 ---
 
-# Clusters health **(FREE)**
+# Clusters health (DEPRECATED) **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4701) in GitLab 10.6.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/208224) from GitLab Ultimate to GitLab Free in 13.2.
+> - [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
+
+WARNING:
+This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. However, you can **still use** Prometheus
+for Kubernetes clusters connected to GitLab by [enabling Prometheus manually](../../../project/integrations/prometheus.md#manual-configuration-of-prometheus).
 
 When [the Prometheus cluster integration is enabled](../../../clusters/integrations.md#prometheus-cluster-integration), GitLab monitors the cluster's health. At the top of the cluster settings page, CPU and Memory utilization is displayed, along with the total amount available. Keeping an eye on cluster resources can be important, if the cluster runs out of memory pods may be shutdown or fail to start.
 
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/apparmor.md b/doc/user/infrastructure/clusters/manage/management_project_applications/apparmor.md
deleted file mode 100644
index ae335a180e8..00000000000
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/apparmor.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-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
----
-
-# Install AppArmor with a cluster management project **(FREE)**
-
-> [Introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/5) in GitLab 14.0.
-
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
-[management project template](../../../../../user/clusters/management_project_template.md), to install AppArmor you should
-uncomment this line from your `helmfile.yaml`:
-
-```yaml
-  - path: applications/apparmor/helmfile.yaml
-```
-
-You can define one or more AppArmor profiles by adding them into
-`applications/apparmor/values.yaml` as the following:
-
-```yaml
-profiles:
-  profile-one: |-
-    profile profile-one {
-      file,
-    }
-```
-
-Refer to the [AppArmor chart](https://gitlab.com/gitlab-org/charts/apparmor) for more information on this chart.
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md b/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md
index 58de5f5e368..5ad1fb81a39 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md
@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - Support for cert-manager v1.4 was [introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/69405) in GitLab 14.3.
 > - [Upgraded](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/23) to cert-manager 1.7 in GitLab 14.8.
 
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
+Assuming you already have a project created from a
 [management project template](../../../../../user/clusters/management_project_template.md), to install cert-manager you should
 uncomment this line from your `helmfile.yaml`:
 
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/cilium.md b/doc/user/infrastructure/clusters/manage/management_project_applications/cilium.md
deleted file mode 100644
index 5d704a2c6df..00000000000
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/cilium.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-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
----
-
-# Install Cilium with a cluster management project **(FREE)**
-
-> [Introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/5) in GitLab 14.0.
-
-[Cilium](https://cilium.io/) is a networking plugin for Kubernetes that you can use to implement
-support for [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
-resources. For more information, see [Network Policies](../../../../../topics/autodevops/stages.md#network-policy).
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an overview, see the
-[Container Network Security Demo for GitLab 12.8](https://www.youtube.com/watch?v=pgUEdhdhoUI).
-
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
-[management project template](../../../../../user/clusters/management_project_template.md), to install cilium you should
-uncomment this line from your `helmfile.yaml`:
-
-```yaml
-  - path: applications/cilium/helmfile.yaml
-```
-
-and update the `applications/cilium/values.yaml` to set the `clusterType`:
-
-```yaml
-# possible values are gke or eks
-clusterType: gke
-```
-
-The `clusterType` variable enables the recommended Helm variables for a corresponding cluster type.
-You can check the recommended variables for each cluster type in the official documentation:
-
-- [Google GKE](https://docs.cilium.io/en/v1.8/gettingstarted/k8s-install-gke/#deploy-cilium)
-- [AWS EKS](https://docs.cilium.io/en/v1.8/gettingstarted/k8s-install-eks/#deploy-cilium)
-
-Do not use `clusterType` for sandbox environments like [minikube](https://minikube.sigs.k8s.io/docs/).
-
-You can customize Cilium's Helm variables by defining the
-`applications/cilium/values.yaml` file in your cluster
-management project. Refer to the
-[Cilium chart](https://github.com/cilium/cilium/tree/master/install/kubernetes/cilium)
-for the available configuration options.
-
-You can check Cilium's installation status on the cluster management page:
-
-- [Project-level cluster](../../../../project/clusters/index.md): Navigate to your project's
-  **Infrastructure > Kubernetes clusters** page.
-- [Group-level cluster](../../../../group/clusters/index.md): Navigate to your group's
-  **Kubernetes** page.
-
-WARNING:
-Installation and removal of the Cilium requires a **manual**
-[restart](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-helm/#restart-unmanaged-pods)
-of all affected pods in all namespaces to ensure that they are
-[managed](https://docs.cilium.io/en/v1.8/operations/troubleshooting/#ensure-managed-pod)
-by the correct networking plugin. Whenever Hubble is enabled, its related pod might require a
-restart depending on whether it started prior to Cilium. For more information, see
-[Failed Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#failed-deployment)
-in the Kubernetes docs.
-
-NOTE:
-Major upgrades might require additional setup steps. For more information, see
-the official [upgrade guide](https://docs.cilium.io/en/v1.8/operations/upgrade/).
-
-By default, Cilium's
-[audit mode](https://docs.cilium.io/en/v1.8/gettingstarted/policy-creation/#enable-policy-audit-mode)
-is enabled. In audit mode, Cilium doesn't drop disallowed packets. You
-can use `policy-verdict` log to observe policy-related decisions. You
-can disable audit mode by adding the following to
-`applications/cilium/values.yaml`:
-
-```yaml
-config:
-  policyAuditMode: false
-
-agent:
-  monitor:
-    eventTypes: ["drop"]
-```
-
-The Cilium monitor log for traffic is logged out by the
-`cilium-monitor` sidecar container. You can check these logs with the following command:
-
-```shell
-kubectl -n gitlab-managed-apps logs -l k8s-app=cilium -c cilium-monitor
-```
-
-You can disable the monitor log in `.gitlab/managed-apps/cilium/values.yaml`:
-
-```yaml
-agent:
-  monitor:
-    enabled: false
-```
-
-The [Hubble](https://github.com/cilium/hubble) monitoring daemon is enabled by default
-and it's set to collect per namespace flow metrics. This metrics are accessible on the
-[Threat Monitoring](../../../../application_security/threat_monitoring/index.md)
-dashboard. You can disable Hubble by adding the following to
-`applications/cilium/values.yaml`:
-
-```yaml
-global:
-  hubble:
-    enabled: false
-```
-
-You can also adjust Helm values for Hubble by using
-`applications/cilium/values.yaml`:
-
-```yaml
-global:
-  hubble:
-    enabled: true
-    metrics:
-      enabled:
-      - 'flow:sourceContext=namespace;destinationContext=namespace'
-```
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/elasticstack.md b/doc/user/infrastructure/clusters/manage/management_project_applications/elasticstack.md
index f9d0948a2bb..7ab99ab3875 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/elasticstack.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/elasticstack.md
@@ -2,28 +2,11 @@
 stage: Monitor
 group: Respond
 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
+remove_date: '2022-08-22'
+redirect_to: '../../index.md'
 ---
 
-# Install Elastic Stack with a cluster management project **(FREE)**
+# Install Elastic Stack with a cluster management project (removed) **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/5) in GitLab 14.0.
-
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
-[management project template](../../../../../user/clusters/management_project_template.md), to install Elastic Stack you should
-uncomment this line from your `helmfile.yaml`:
-
-```yaml
-  - path: applications/elastic-stack/helmfile.yaml
-```
-
-Elastic Stack is installed by default into the `gitlab-managed-apps` namespace of your cluster.
-
-You can check the default
-[`values.yaml`](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/blob/master/applications/elastic-stack/values.yaml)
-we set for this chart.
-
-You can customize the installation of Elastic Stack by updating the
-`applications/elastic-stack/values.yaml` file in your cluster
-management project. Refer to the
-[chart](https://gitlab.com/gitlab-org/charts/elastic-stack) for all
-available configuration options.
+This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/346485) in GitLab 14.8
+and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/360182) in 15.0.
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/falco.md b/doc/user/infrastructure/clusters/manage/management_project_applications/falco.md
deleted file mode 100644
index 50401e9a391..00000000000
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/falco.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-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
----
-
-# Install Falco with a cluster management project **(FREE)**
-
-> [Introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/5) in GitLab 14.0.
-
-GitLab Container Host Security Monitoring uses [Falco](https://falco.org/)
-as a runtime security tool that listens to the Linux kernel using eBPF. Falco parses system calls
-and asserts the stream against a configurable rules engine in real-time. For more information, see
-[Falco's Documentation](https://falco.org/docs/).
-
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
-[management project template](../../../../../user/clusters/management_project_template.md), to install Falco you should
-uncomment this line from your `helmfile.yaml`:
-
-```yaml
-  - path: applications/falco/helmfile.yaml
-```
-
-You can customize Falco's Helm variables by defining the
-`applications/falco/values.yaml` file in your cluster
-management project. Refer to the
-[Falco chart](https://github.com/falcosecurity/charts/tree/master/falco)
-for the available configuration options.
-
-WARNING:
-By default eBPF support is enabled and Falco uses an
-[eBPF probe](https://falco.org/docs/event-sources/drivers/#using-the-ebpf-probe)
-to pass system calls to user space. If your cluster doesn't support this, you can
-configure it to use Falco kernel module instead by adding the following to
-`applications/falco/values.yaml`:
-
-```yaml
-ebpf:
-  enabled: false
-```
-
-In rare cases where probe installation on your cluster isn't possible and the kernel/probe
-isn't pre-compiled, you may need to manually prepare the kernel module or eBPF probe with
-[`driverkit`](https://github.com/falcosecurity/driverkit#against-a-kubernetes-cluster)
-and install it on each cluster node.
-
-By default, Falco is deployed with a limited set of rules. To add more rules, add
-the following to `applications/falco/values.yaml` (you can get examples from
-[Cloud Native Security Hub](https://securityhub.dev/)):
-
-```yaml
-customRules:
-  file-integrity.yaml: |-
-    - rule: Detect New File
-      desc: detect new file created
-      condition: >
-        evt.type = chmod or evt.type = fchmod
-      output: >
-        File below a known directory opened for writing (user=%user.name
-        command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2])
-      priority: ERROR
-      tags: [filesystem]
-    - rule: Detect New Directory
-      desc: detect new directory created
-      condition: >
-        mkdir
-      output: >
-        File below a known directory opened for writing (user=%user.name
-        command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2])
-      priority: ERROR
-      tags: [filesystem]
-```
-
-By default, Falco only outputs security events to logs as JSON objects. To set it to output to an
-[external API](https://falco.org/docs/alerts/#https-output-send-alerts-to-an-https-end-point)
-or [application](https://falco.org/docs/alerts/#program-output),
-add the following to `applications/falco/values.yaml`:
-
-```yaml
-falco:
-  programOutput:
-    enabled: true
-    keepAlive: false
-    program: mail -s "Falco Notification" someone@example.com
-
-  httpOutput:
-    enabled: true
-    url: http://some.url
-```
-
-You can check these logs with the following command:
-
-```shell
-kubectl -n gitlab-managed-apps logs -l app=falco
-```
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/fluentd.md b/doc/user/infrastructure/clusters/manage/management_project_applications/fluentd.md
deleted file mode 100644
index ea3a3503f9b..00000000000
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/fluentd.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-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
----
-
-# Install Fluentd with a cluster management project **(FREE)**
-
-> [Introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/5) in GitLab 14.0.
-
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
-[management project template](../../../../../user/clusters/management_project_template.md), to install Fluentd you should
-uncomment this line from your `helmfile.yaml`:
-
-```yaml
-  - path: applications/fluentd/helmfile.yaml
-```
-
-You can also review the default values set for this chart in the
-[`values.yaml`](https://github.com/helm/charts/blob/master/stable/fluentd/values.yaml) file.
-
-You can customize the installation of Fluentd by defining
-`applications/fluentd/values.yaml` file in your cluster management
-project. Refer to the
-[configuration chart](https://github.com/helm/charts/tree/master/stable/fluentd#configuration)
-for the current development release of Fluentd for all available configuration options.
-
-The configuration chart link points to the current development release, which
-may differ from the version you have installed. To ensure compatibility, switch
-to the specific branch or tag you are using.
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/ingress.md b/doc/user/infrastructure/clusters/manage/management_project_applications/ingress.md
index 503f077df14..7983a640577 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/ingress.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/ingress.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/5) in GitLab 14.0.
 
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
+Assuming you already have a project created from a
 [management project template](../../../../../user/clusters/management_project_template.md), to install Ingress you should
 uncomment this line from your `helmfile.yaml`:
 
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/prometheus.md b/doc/user/infrastructure/clusters/manage/management_project_applications/prometheus.md
index f76c7363a83..383e857bb20 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/prometheus.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/prometheus.md
@@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 open-source monitoring and alerting system for supervising your
 deployed applications.
 
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
+Assuming you already have a project created from a
 [management project template](../../../../../user/clusters/management_project_template.md), to install Prometheus you should
 uncomment this line from your `helmfile.yaml`:
 
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/runner.md b/doc/user/infrastructure/clusters/manage/management_project_applications/runner.md
index 4faf5f46418..ef7c4637607 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/runner.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/runner.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/5) in GitLab 14.0.
 
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
+Assuming you already have a project created from a
 [management project template](../../../../../user/clusters/management_project_template.md), to install GitLab Runner you should
 uncomment this line from your `helmfile.yaml`:
 
@@ -35,7 +35,7 @@ These values can be specified using [CI/CD variables](../../../../../ci/variable
 
 The methods of specifying these values are mutually exclusive. Either specify variables `GITLAB_RUNNER_REGISTRATION_TOKEN` and `CI_SERVER_URL` as CI variables (recommended) or provide values for `runnerRegistrationToken:` and `gitlabUrl:` in `applications/gitlab-runner/values.yaml.gotmpl`.
 
-The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../../../../ci/variables/index.md#protect-a-cicd-variable) and [masked variable](../../../../../ci/variables/index.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml.gotmpl` file.
+The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../../../../ci/variables/index.md#protected-cicd-variables) and [masked variable](../../../../../ci/variables/index.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml.gotmpl` file.
 
 You can customize the installation of GitLab Runner by defining
 `applications/gitlab-runner/values.yaml.gotmpl` file in your cluster
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/sentry.md b/doc/user/infrastructure/clusters/manage/management_project_applications/sentry.md
index b968e63d632..d2d314b649e 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/sentry.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/sentry.md
@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 The Sentry Helm chart [recommends](https://github.com/helm/charts/blob/f6e5784f265dd459c5a77430185d0302ed372665/stable/sentry/values.yaml#L284-L285)
 at least 3 GB of available RAM for database migrations.
 
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
+Assuming you already have a project created from a
 [management project template](../../../../../user/clusters/management_project_template.md), to install Sentry you should
 uncomment this line from your `helmfile.yaml`:
 
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/vault.md b/doc/user/infrastructure/clusters/manage/management_project_applications/vault.md
index 4618a95f986..06e67b78c91 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/vault.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/vault.md
@@ -20,7 +20,7 @@ control. Therefore, if GitLab is compromised, the security of this Vault instanc
 avoid this security risk, GitLab recommends using your own HashiCorp Vault to leverage
 [external secrets with CI](../../../../../ci/secrets/index.md).
 
-Assuming you already have a [Cluster management project](../../../../../user/clusters/management_project.md) created from a
+Assuming you already have a project created from a
 [management project template](../../../../../user/clusters/management_project_template.md), to install Vault you should
 uncomment this line from your `helmfile.yaml`:
 
diff --git a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
index 61ec0a559f0..7b2b5b4afd4 100644
--- a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
+++ b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
@@ -9,19 +9,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 To connect your Kubernetes cluster with GitLab, you can use:
 
 - [A GitOps workflow](../../clusters/agent/gitops.md).
-- [A GitLab CI/CD workflow](../../clusters/agent/ci_cd_tunnel.md).
+- [A GitLab CI/CD workflow](../../clusters/agent/ci_cd_workflow.md).
 - [A certificate-based integration](index.md).
 
 The certificate-based integration is
 [**deprecated**](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/)
-in GitLab 14.5. It is expected to be
-[turned off by default in 15.0](../../../update/deprecations.md#certificate-based-integration-with-kubernetes)
-and removed in GitLab 15.6.
+in GitLab 14.5. The sunsetting plans are described:
+
+- for [GitLab.com customers](../../../update/deprecations.md#saas-certificate-based-integration-with-kubernetes).
+- for [Self-managed customers](../../../update/deprecations.md#self-managed-certificate-based-integration-with-kubernetes).
 
 If you are using the certificate-based integration, you should move to another workflow as soon as possible.
 
 As a general rule, to migrate clusters that rely on GitLab CI/CD,
-you can use the [CI/CD workflow](../../clusters/agent/ci_cd_tunnel.md).
+you can use the [CI/CD workflow](../../clusters/agent/ci_cd_workflow.md).
 This workflow uses an agent to connect to your cluster. The agent:
 
 - Is not exposed to the internet.
@@ -39,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_tunnel.md#use-impersonation-to-restrict-project-and-group-access)
+The GitLab agent uses [impersonation](../../clusters/agent/ci_cd_workflow.md#use-impersonation-to-restrict-project-and-group-access)
 strategies to deploy to your cluster with restricted account access. To do so:
 
 1. Choose the impersonation strategy that suits your needs.
@@ -48,30 +49,55 @@ strategies to deploy to your cluster with restricted account access. To do so:
 
 ### Migrate from Auto DevOps
 
-To configure your Auto DevOps project to use the GitLab agent:
-
-1. Follow the steps to [install an agent](../../clusters/agent/install/index.md) in your cluster.
-1. Go to the project where you use Auto DevOps.
-1. On the left sidebar, select **Settings > CI/CD** and expand **Variables**.
-1. Select **Add new variable**.
-1. Add `KUBE_CONTEXT` as the key, `path/to/agent/project:agent-name` as the value, and select the environment scope of your choice.
+In your Auto DevOps project, you can use the GitLab agent to connect with your Kubernetes cluster.
+
+1. [Install an agent](../../clusters/agent/install/index.md) in your cluster.
+1. In GitLab, go to the project where you use Auto DevOps.
+1. Add three variables. On the left sidebar, select **Settings > CI/CD** and expand **Variables**.
+   - Add a key called `KUBE_INGRESS_BASE_DOMAIN` with the application deployment domain as the value.
+   - Add a key called `KUBE_CONTEXT` with a value like `path/to/agent/project:agent-name`.
+     Select the environment scope of your choice.
+     If you are not sure what your agent’s context is, edit your `.gitlab-ci.yml` file and add a job to see the available contexts:
+
+     ```yaml
+      deploy:
+       image:
+         name: bitnami/kubectl:latest
+         entrypoint: [""]
+       script:
+       - kubectl config get-contexts
+      ```
+
+   - Add a key called `KUBE_NAMESPACE` with a value of the Kubernetes namespace for your deployments to target. Set the same environment scope.
 1. Select **Add variable**.
-1. Repeat the process to add another variable, `KUBE_NAMESPACE`, setting the value for the Kubernetes namespace you want your deployments to target, and set the same environment scope from the previous step.
 1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
 1. From the certificate-based clusters section, open the cluster that serves the same environment scope.
 1. Select the **Details** tab and disable the cluster.
-1. To activate the changes, on the left sidebar, select **CI/CD > Pipelines** and then **Run pipeline**.
+1. Edit your `.gitlab-ci.yml` file and ensure it's using the Auto DevOps template. For example:
+
+   ```yaml
+   include:
+     template: Auto-DevOps.gitlab-ci.yml
+
+   variables:
+     KUBE_INGRESS_BASE_DOMAIN: 74.220.23.215.nip.io
+     KUBE_CONTEXT: "gitlab-examples/ops/gitops-demo/k8s-agents:demo-agent"
+     KUBE_NAMESPACE: "demo-agent"
+   ```
+
+1. To test your pipeline, on the left sidebar, select **CI/CD > Pipelines** and then **Run pipeline**.
 
 For an example, [view this project](https://gitlab.com/gitlab-examples/ops/gitops-demo/hello-world-service).
 
 ### Migrate generic deployments
 
-Follow the process for the [CI/CD workflow](../../clusters/agent/ci_cd_tunnel.md).
+Follow the process for the [CI/CD workflow](../../clusters/agent/ci_cd_workflow.md).
 
 ## Migrate from GitLab Managed applications
 
-[GitLab Managed Apps (GMA)](../../clusters/applications.md#gitlab-managed-apps-deprecated) were deprecated in GitLab 14.0, and
-the agent for Kubernetes does not support them. To migrate from GMA to the agent, go through the following steps:
+GitLab Managed Apps (GMA) were deprecated in GitLab 14.0, and removed in GitLab 15.0.
+The agent for Kubernetes does not support them. To migrate from GMA to the
+agent, go through the following steps:
 
 1. [Migrate from GitLab Managed Apps to a cluster management project](../../clusters/migrating_from_gma_to_project_template.md).
 1. [Migrate the cluster management project to use the agent](../../clusters/management_project_template.md).