Fix Gitlab possessives in Configure docs

The documentation for Configure contained some instances of GitLab
with the possessive form, which we shouldn't use for legal reasons.

doc/development/agent/identity.md

@@ -56,7 +56,7 @@ agent uses this token to authenticate with GitLab. This token is a random string
 and does not encode any information in it, but it is secret and must
 be treated with care. Store it as a `Secret` in Kubernetes.
 
-Each agent can have 0 or more tokens in GitLab's database. Having several valid
+Each agent can have 0 or more tokens in a GitLab database. Having several valid
 tokens helps you rotate tokens without needing to re-register an agent. Each token
 record in the database has the following fields:
 

doc/development/kubernetes.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Kubernetes integration - development guidelines
 
-This document provides various guidelines when developing for GitLab's
+This document provides various guidelines when developing for the GitLab
 [Kubernetes integration](../user/project/clusters/index.md).
 
 ## Development

doc/topics/autodevops/index.md

@@ -76,7 +76,7 @@ innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it
 in multiple ways:
 
 - Auto DevOps works with any Kubernetes cluster; you're not limited to running
-  on GitLab's infrastructure. (Note that many features also work without Kubernetes).
+  on infrastructure managed by GitLab. (Note that many features also work without Kubernetes).
 - There is no additional cost (no markup on the infrastructure costs), and you
   can use a Kubernetes cluster you host or Containers as a Service on any
   public cloud (for example, [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)).
@@ -316,7 +316,7 @@ simplify configuration and prevent any unforeseen issues.
 
 ### Install applications behind a proxy
 
-GitLab's Helm integration does not support installing applications when
+The GitLab integration with Helm does not support installing applications when
 behind a proxy. Users who want to do so must inject their proxy settings
 into the installation pods at runtime, such as by using a
 [`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/):

doc/topics/autodevops/quick_start_guide.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 This step-by-step guide helps you use [Auto DevOps](index.md) to
 deploy a project hosted on GitLab.com to Google Kubernetes Engine.
 
-You are using GitLab's native Kubernetes integration, so you don't need
+You are using the GitLab native Kubernetes integration, so you don't need
 to create a Kubernetes cluster manually using the Google Cloud Platform console.
 You are creating and deploying a simple application that you create from a GitLab template.
 
@@ -32,13 +32,13 @@ or Google Drive, or create a new one.
 NOTE:
 Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial),
 and in partnership with Google, GitLab is able to offer an additional $200 for new
-GCP accounts to get started with GitLab's Google Kubernetes Engine Integration.
+GCP accounts to get started with the GitLab integration with Google Kubernetes Engine.
 [Follow this link](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form)
 and apply for credit.
 
 ## Create a new project from a template
 
-We are using one of GitLab's project templates to get started. As the name suggests,
+We are using a GitLab project template to get started. As the name suggests,
 those projects provide a bare-bones application built on some well-known frameworks.
 
 1. In GitLab, click the plus icon (**{plus-square}**) at the top of the navigation bar, and select

doc/topics/autodevops/requirements.md

@@ -28,15 +28,15 @@ To make full use of Auto DevOps with Kubernetes, you need:
      [Auto Deploy for Kubernetes 1.16+](stages.md#kubernetes-116).
   1. NGINX Ingress. You can deploy it to your Kubernetes cluster by installing
      the [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress),
-     after configuring GitLab's Kubernetes integration in the previous step.
+     after configuring the GitLab integration with Kubernetes in the previous step.
 
      Alternatively, you can use the
      [`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
      Helm chart to install Ingress manually.
 
      NOTE:
-     If you use your own Ingress instead of the one provided by GitLab's managed
-     apps, ensure you're running at least version 0.9.0 of NGINX Ingress and
+     If you use your own Ingress instead of the one provided by GitLab Managed
+     Apps, ensure you're running at least version 0.9.0 of NGINX Ingress and
      [enable Prometheus metrics](https://github.com/helm/charts/tree/master/stable/nginx-ingress#prometheus-metrics)
      for the response metrics to appear. You must also
      [annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
@@ -64,7 +64,7 @@ To make full use of Auto DevOps with Kubernetes, you need:
   You can configure Docker-based runners to autoscale as well, using
   [Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html).
 
-  If you've configured GitLab's Kubernetes integration in the first step, you
+  If you've configured the GitLab integration with Kubernetes in the first step, you
   can deploy it to your cluster by installing the
   [GitLab-managed app for GitLab Runner](../../user/clusters/applications.md#gitlab-runner).
 
@@ -77,7 +77,7 @@ To make full use of Auto DevOps with Kubernetes, you need:
 
   To enable Auto Monitoring, you need Prometheus installed either inside or
   outside your cluster, and configured to scrape your Kubernetes cluster.
-  If you've configured GitLab's Kubernetes integration, you can deploy it to
+  If you've configured the GitLab integration with Kubernetes, you can deploy it to
   your cluster by installing the
   [GitLab-managed app for Prometheus](../../user/clusters/applications.md#prometheus).
 
@@ -95,8 +95,8 @@ To make full use of Auto DevOps with Kubernetes, you need:
   a native Kubernetes certificate management controller that helps with issuing
   certificates. Installing cert-manager on your cluster issues a
   [Let’s Encrypt](https://letsencrypt.org/) certificate and ensures the
-  certificates are valid and up-to-date. If you've configured GitLab's Kubernetes
-  integration, you can deploy it to your cluster by installing the
+  certificates are valid and up-to-date. If you've configured the GitLab integration
+  with Kubernetes, you can deploy it to your cluster by installing the
   [GitLab-managed app for cert-manager](../../user/clusters/applications.md#cert-manager).
 
 If you don't have Kubernetes or Prometheus installed, then

doc/topics/autodevops/stages.md

@@ -618,7 +618,7 @@ may require commands to be wrapped as follows:
 Some of the reasons you may need to wrap commands:
 
 - Attaching using `kubectl exec`.
-- Using GitLab's [Web Terminal](../../ci/environments/index.md#web-terminals).
+- Using the GitLab [Web Terminal](../../ci/environments/index.md#web-terminals).
 
 For example, to start a Rails console from the application root directory, run:
 

doc/user/clusters/applications.md

@@ -77,10 +77,10 @@ in a pod within the `gitlab-managed-apps` namespace inside the cluster.
   with a local [Tiller](https://v2.helm.sh/docs/glossary/#tiller) server. Prior
   to [GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/209736), GitLab
   used an in-cluster Tiller server in the `gitlab-managed-apps` namespace. You
-  can safely uninstall the server from GitLab's application page if you have
+  can safely uninstall the server from the GitLab application page if you have
   previously installed it. This doesn't affect your other applications.
 
-GitLab's Helm integration does not support installing applications behind a proxy,
+The GitLab Helm integration does not support installing applications behind a proxy,
 but a [workaround](../../topics/autodevops/index.md#install-applications-behind-a-proxy)
 is available.
 
@@ -286,7 +286,7 @@ of a WAF are:
 
 By default, GitLab provides you with a WAF known as [`ModSecurity`](https://www.modsecurity.org/),
 which is a toolkit for real-time web application monitoring, logging, and access
-control. GitLab's offering applies the [OWASP's Core Rule Set](https://www.modsecurity.org/CRS/Documentation/),
+control. GitLab applies the [OWASP's Core Rule Set](https://www.modsecurity.org/CRS/Documentation/),
 which provides generic attack detection capabilities.
 
 This feature:
@@ -301,7 +301,7 @@ This feature:
 
 To enable WAF, switch its respective toggle to the enabled position when installing or updating [Ingress application](#ingress).
 
-If this is your first time using GitLab's WAF, we recommend you follow the
+If this is your first time using the GitLab WAF, we recommend you follow the
 [quick start guide](../../topics/web_application_firewall/quick_start_guide.md).
 
 There is a small performance overhead by enabling ModSecurity. If this is

doc/user/clusters/cost_management.md

@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Cluster cost management provides insights into cluster resource usage. GitLab provides an example
 [`kubecost-cost-model`](https://gitlab.com/gitlab-examples/kubecost-cost-model/)
-project that uses GitLab's Prometheus integration and
+project that uses the GitLab Prometheus integration and
 [Kubecost's `cost-model`](https://github.com/kubecost/cost-model) to provide cluster cost
 insights within GitLab:
 
@@ -28,7 +28,7 @@ permissions in a project or group.
      need to change this value if you use a non-managed Prometheus.
    - Adds the necessary annotations to the deployment manifest to be scraped by
      GitLab-managed Prometheus.
-   - Changes the Google Pricing API access key to GitLab's access key.
+   - Changes the Google Pricing API access key to the GitLab access key.
    - Contains definitions for a custom GitLab Metrics dashboard to show the cost insights.
 1. Connect GitLab with Prometheus, depending on your configuration:
    - *If Prometheus is already configured,* navigate to **Settings > Integrations > Prometheus**

doc/user/infrastructure/index.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Motivation
 
 The Terraform integration features within GitLab enable your GitOps / Infrastructure-as-Code (IaC)
-workflows to tie into GitLab's authentication and authorization. These features focus on
+workflows to tie into GitLab authentication and authorization. These features focus on
 lowering the barrier to entry for teams to adopt Terraform, collaborate effectively within
 GitLab, and support Terraform best practices.
 

doc/user/project/clusters/add_eks_clusters.md

@@ -10,7 +10,7 @@ GitLab supports adding new and existing EKS clusters.
 
 ## EKS requirements
 
-Before creating your first cluster on Amazon EKS with GitLab's integration, make sure the following
+Before creating your first cluster on Amazon EKS with the GitLab integration, make sure the following
 requirements are met:
 
 - An [Amazon Web Services](https://aws.amazon.com/) account is set up and you are able to log in.

doc/user/project/clusters/add_gke_clusters.md

@@ -10,7 +10,7 @@ GitLab supports adding new and existing GKE clusters.
 
 ## GKE requirements
 
-Before creating your first cluster on Google GKE with GitLab's integration, make sure the following
+Before creating your first cluster on Google GKE with GitLab integration, make sure the following
 requirements are met:
 
 - A [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account)

doc/user/project/clusters/add_remove_clusters.md

@@ -22,7 +22,7 @@ NOTE:
 Every new Google Cloud Platform (GCP) account receives
 [$300 in credit upon sign up](https://console.cloud.google.com/freetrial).
 In partnership with Google, GitLab is able to offer an additional $200 for new GCP
-accounts to get started with GitLab's Google Kubernetes Engine Integration.
+accounts to get started with the GitLab integration with Google Kubernetes Engine.
 [Follow this link](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form)
 to apply for credit.
 

doc/user/project/clusters/runbooks/index.md

@@ -25,7 +25,7 @@ pre-written code blocks or database queries against a given environment.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45912) in GitLab 11.4.
 
-The JupyterHub app offered via GitLab’s Kubernetes integration now ships
+The JupyterHub app offered via the GitLab Kubernetes integration now ships
 with Nurtch’s Rubix library, providing a simple way to create DevOps
 runbooks. A sample runbook is provided, showcasing common operations. While
 Rubix makes it simple to create common Kubernetes and AWS workflows, you can
@@ -41,7 +41,7 @@ To create an executable runbook, you need:
 
 - **Kubernetes** - A Kubernetes cluster is required to deploy the rest of the
   applications. The simplest way to get started is to add a cluster using one
-  of [GitLab's integrations](../add_remove_clusters.md#create-new-cluster).
+  of the [GitLab integrations](../add_remove_clusters.md#create-new-cluster).
 - **Ingress** - Ingress can provide load balancing, SSL termination, and name-based
   virtual hosting. It acts as a web proxy for your applications.
 - **JupyterHub** - [JupyterHub](https://jupyterhub.readthedocs.io/) is a multi-user

doc/user/project/clusters/serverless/index.md

@@ -49,7 +49,7 @@ To run Knative on GitLab, you need:
      clone the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get
      started.
 1. **Kubernetes Cluster:** An RBAC-enabled Kubernetes cluster is required to deploy Knative.
-   The simplest way to get started is to add a cluster using GitLab's [GKE integration](../add_remove_clusters.md).
+   The simplest way to get started is to add a cluster using the GitLab [GKE integration](../add_remove_clusters.md).
    The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
 1. **GitLab Runner:** A runner is required to run the CI jobs that deploy serverless
    applications or functions onto your cluster. You can install GitLab Runner
@@ -73,7 +73,7 @@ To run Knative on GitLab, you need:
 1. **Logging** (optional): Configuring logging allows you to view and search request logs for your serverless function/application.
    See [Configuring logging](#configuring-logging) for more information.
 
-## Installing Knative via GitLab's Kubernetes integration
+## Installing Knative via the GitLab Kubernetes integration
 
 The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB
 memory. **RBAC must be enabled.**
@@ -123,7 +123,7 @@ which already has Knative installed. You must do the following:
    - For a GitLab managed cluster, if you added the cluster in [GitLab 12.1 or later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30235),
      then GitLab already has the required access and you can proceed to the next step.
 
-     Otherwise, you need to manually grant GitLab's service account the ability to manage
+     Otherwise, you need to manually grant the GitLab service account the ability to manage
      resources in the `serving.knative.dev` API group. Since every GitLab service account
      has the `edit` cluster role, the simplest way to do this is with an
      [aggregated ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)