Add latest changes from gitlab-org/gitlab@master

25 files changed, 879 insertions, 94 deletions

diff --git a/doc/administration/lfs/index.md b/doc/administration/lfs/index.md
index ee5cd04f3d6..e4475e877d8 100644
--- a/doc/administration/lfs/index.md
+++ b/doc/administration/lfs/index.md
@@ -401,7 +401,7 @@ To delete these references:
 
 If you configure GitLab to [disable TLS v1.2](https://docs.gitlab.com/omnibus/settings/nginx.html)
 and only enable TLS v1.3 connections, LFS operations require a
-[Git LFS client](https://git-lfs.github.com) version 2.11.0 or later. If you use
+[Git LFS client](https://git-lfs.com/) version 2.11.0 or later. If you use
 a Git LFS client earlier than version 2.11.0, GitLab displays an error:
 
 ```plaintext
diff --git a/doc/ci/cloud_services/azure/index.md b/doc/ci/cloud_services/azure/index.md
index 912e6597985..29d27e440ec 100644
--- a/doc/ci/cloud_services/azure/index.md
+++ b/doc/ci/cloud_services/azure/index.md
@@ -34,7 +34,7 @@ To complete this tutorial:
 1. [Grant permissions for the service principal](#grant-permissions-for-the-service-principal).
 1. [Retrieve a temporary credential](#retrieve-a-temporary-credential).
 
-For more information, review Azure's documentation on [Workload identity federation](https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation).
+For more information, review Azure's documentation on [Workload identity federation](https://learn.microsoft.com/en-us/azure/active-directory/workload-identities/workload-identity-federation).
 
 ## Create Azure AD application and service principal
 
diff --git a/doc/ci/cloud_services/index.md b/doc/ci/cloud_services/index.md
index 54cadc9e1b6..eadf0656d48 100644
--- a/doc/ci/cloud_services/index.md
+++ b/doc/ci/cloud_services/index.md
@@ -38,8 +38,7 @@ ID tokens support cloud providers with OIDC, including:
 NOTE:
 Configuring OIDC enables JWT token access to the target environments for all pipelines.
 When you configure OIDC for a pipeline, you should complete a software supply chain security
-review for the pipeline, focusing on the additional access. You can use the [software supply chain security awareness assessment](https://about.gitlab.com/quiz/software-supply-chain-security/)
-as a starting point, and for more information about supply chain attacks, see
+review for the pipeline, focusing on the additional access. For more information about supply chain attacks, see
 [How a DevOps Platform helps protect against supply chain attacks](https://about.gitlab.com/blog/2021/04/28/devops-platform-supply-chain-attacks/).
 
 ## Use cases
diff --git a/doc/ci/pipelines/cicd_minutes.md b/doc/ci/pipelines/cicd_minutes.md
index 571a47c5426..190c732e48b 100644
--- a/doc/ci/pipelines/cicd_minutes.md
+++ b/doc/ci/pipelines/cicd_minutes.md
@@ -5,38 +5,38 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# CI/CD minutes quota **(PREMIUM)**
+# Compute quota **(PREMIUM)**
 
 NOTE:
 The term `CI/CD minutes` is being renamed to `units of compute`. During this transition, you might see references in the UI and documentation to `CI/CD minutes`, `CI minutes`, `pipeline minutes`, `CI pipeline minutes`, `pipeline minutes quota`, and `units of compute`. For more information, see [epic 2150](https://gitlab.com/groups/gitlab-com/-/epics/2150).
 
 Administrators can limit the amount of time that projects can use to run jobs on
 [shared runners](../runners/runners_scope.md#shared-runners) each month. This limit
-is tracked with a quota of CI/CD minutes.
+is tracked with a compute quota.
 
 By default, one minute of execution time by a single job uses
-one CI/CD minute. The total amount of CI/CD minutes used by a pipeline is
+one unit of compute. The total execution time for a pipeline is
 [the sum of all its jobs' durations](#how-compute-usage-is-calculated).
-Jobs can run concurrently, so the total CI/CD minute usage can be higher than the
+Jobs can run concurrently, so the total usage can be higher than the
 end-to-end duration of a pipeline.
 
 On GitLab.com:
 
-- CI/CD minutes quotas are enabled for all projects, but certain
-  projects [consume CI/CD minutes at a slower rate](#cost-factor).
-- The base monthly CI/CD minutes quota for a GitLab.com [namespace](../../user/namespace/index.md)
+- Compute quotas are enabled for all projects, but certain
+  projects [consume units of compute at a slower rate](#cost-factor).
+- The base monthly compute quota for a GitLab.com [namespace](../../user/namespace/index.md)
   is determined by its [license tier](https://about.gitlab.com/pricing/).
-- You can [purchase additional CI/CD minutes](#purchase-additional-cicd-minutes)
-  if you need more than the number of CI/CD minutes in your monthly quota.
+- You can [purchase additional units of compute](#purchase-additional-units-of-compute)
+  if you need more than the amount of compute in your monthly quota.
 
 On self-managed GitLab instances:
 
-- CI/CD minutes quotas are disabled by default.
-- When enabled, CI/CD minutes quotas apply to private projects only.
-- Administrators can [assign more CI/CD minutes](#set-the-compute-quota-for-a-specific-namespace)
-  if a namespace uses all the CI/CD minutes in its monthly quota.
+- Compute quotas are disabled by default.
+- When enabled, compute quotas apply to private projects only.
+- Administrators can [assign more units of compute](#set-the-compute-quota-for-a-specific-namespace)
+  if a namespace uses all its monthly quota.
 
-[Project runners](../runners/runners_scope.md#project-runners) are not subject to a quota of CI/CD minutes.
+[Project runners](../runners/runners_scope.md#project-runners) are not subject to a compute quota.
 
 ## Set the compute quota for all namespaces
 
@@ -129,64 +129,64 @@ The projects list shows [personal projects](../../user/project/working_with_proj
 with compute usage or shared runners usage in the current month only. The list
 is sorted in descending order of compute usage.
 
-## Purchase additional CI/CD minutes **(FREE SAAS)**
+## Purchase additional units of compute **(FREE SAAS)**
 
-If you're using GitLab SaaS, you can purchase additional packs of CI/CD minutes.
-These additional CI/CD minutes:
+If you're using GitLab SaaS, you can purchase additional packs of units of compute.
+These additional units of compute:
 
 - Are used only after the monthly quota included in your subscription runs out.
 - Are carried over to the next month, if any remain at the end of the month.
-- Are valid for 12 months from date of purchase or until all minutes are consumed, whichever comes first. Expiry of minutes is not enforced.
+- Are valid for 12 months from date of purchase or until all units of compute are consumed, whichever comes first. Expiry of units of compute is not enforced.
 
 For example, with a GitLab SaaS Premium license:
 
-- You have `10,000` monthly minutes.
-- You purchase an additional `5,000` minutes.
-- Your total limit is `15,000` minutes.
+- You have `10,000` monthly units of compute.
+- You purchase an additional `5,000` units of compute.
+- Your total limit is `15,000` units of compute.
 
-If you use `13,000` minutes during the month, the next month your additional minutes become
-`2,000`. If you use `9,000` minutes during the month, your additional minutes remain the same.
+If you use `13,000` units of compute during the month, the next month your additional units of compute become
+`2,000`. If you use `9,000` units of compute during the month, your additional units of compute remain the same.
 
-If you bought additional CI/CD minutes while on a trial subscription, those minutes are available after the trial ends or you upgrade to a paid plan.
+If you bought additional units of compute while on a trial subscription, those units of compute are available after the trial ends or you upgrade to a paid plan.
 
-You can find pricing for additional CI/CD minutes on the
+You can find pricing for additional units of compute on the
 [GitLab Pricing page](https://about.gitlab.com/pricing/).
 
-### Purchase CI/CD minutes for a group **(FREE SAAS)**
+### Purchase units of compute for a group **(FREE SAAS)**
 
 Prerequisite:
 
 - You must have the Owner role for the group.
 
-You can purchase additional CI/CD minutes for your group.
-You cannot transfer purchased CI/CD minutes from one group to another,
+You can purchase additional units of compute for your group.
+You cannot transfer purchased units of compute from one group to another,
 so be sure to select the correct group.
 
 1. On the top bar, select **Main menu > Groups** and find your group.
 1. On the left sidebar, select **Settings > Usage Quotas**.
 1. Select **Pipelines**.
-1. Select **Buy additional minutes**.
+1. Select **Buy additional units of compute**.
 1. Complete the details of the transaction.
 
-After your payment is processed, the additional CI/CD minutes are added to your group
+After your payment is processed, the additional units of compute are added to your group
 namespace.
 
-### Purchase CI/CD minutes for a personal namespace **(FREE SAAS)**
+### Purchase units of compute for a personal namespace **(FREE SAAS)**
 
 Prerequisite:
 
 - The namespace must be your personal namespace.
 
-To purchase additional minutes for your personal namespace:
+To purchase additional units of compute for your personal namespace:
 
 1. On the top bar, in the upper-right corner, select your avatar.
 1. Select **Edit profile**.
 1. On the left sidebar, select **Usage Quotas**.
-1. Select **Buy additional minutes**. GitLab redirects you to the Customers Portal.
-1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, select **Buy more CI minutes**,
+1. Select **Buy additional units of compute**. GitLab redirects you to the Customers Portal.
+1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, select **Buy more units of compute**,
    and complete the details of the transaction.
 
-After your payment is processed, the additional CI/CD minutes are added to your personal
+After your payment is processed, the additional units of compute are added to your personal
 namespace.
 
 ## How compute usage is calculated
diff --git a/doc/ci/testing/test_coverage_visualization.md b/doc/ci/testing/test_coverage_visualization.md
index 2fcd1ecfad2..8ebe636e1ad 100644
--- a/doc/ci/testing/test_coverage_visualization.md
+++ b/doc/ci/testing/test_coverage_visualization.md
@@ -297,7 +297,7 @@ run tests:
 The following [`.gitlab-ci.yml`](../yaml/index.md) example for PHP uses [PHPUnit](https://phpunit.readthedocs.io/)
 to collect test coverage data and generate the report.
 
-With a minimal [`phpunit.xml`](https://phpunit.readthedocs.io/en/9.5/configuration.html) file (you may reference
+With a minimal [`phpunit.xml`](https://docs.phpunit.de/en/10.2/configuration.html) file (you may reference
 [this example repository](https://gitlab.com/yookoala/code-coverage-visualization-with-php/)), you can run the test and
 generate the `coverage.xml`:
 
diff --git a/doc/ci/testing/unit_test_report_examples.md b/doc/ci/testing/unit_test_report_examples.md
index c63e225a2a7..1b1600b3d99 100644
--- a/doc/ci/testing/unit_test_report_examples.md
+++ b/doc/ci/testing/unit_test_report_examples.md
@@ -260,7 +260,7 @@ test:
 
 This example uses [PHPUnit](https://phpunit.de/) with the `--log-junit` flag.
 You can also add this option using
-[XML](https://phpunit.readthedocs.io/en/9.5/configuration.html#the-junit-element)
+[XML](https://docs.phpunit.de/en/10.2/configuration.html#the-junit-element)
 in the `phpunit.xml` configuration file.
 
 ```yaml
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index d68bc194266..90f11234b46 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -110,8 +110,8 @@ Check accessibility using your browser's _accessibility inspector_ ([Chrome](htt
 
 When the design is ready, _before_ starting its implementation:
 
-- Share design specifications in the related issue, preferably through a [Figma link](https://help.figma.com/hc/en-us/articles/360040531773-Share-Files-with-anyone-using-Link-Sharing#copy-link)
-  link or [GitLab Designs feature](../../user/project/issues/design_management.md).
+- Share design specifications in the related issue, preferably through a [Figma link](https://help.figma.com/hc/en-us/articles/360040531773-Share-Files-with-anyone-using-Link-Sharing#Copy_link)
+  or [GitLab Designs feature](../../user/project/issues/design_management.md).
   See [when you should use each tool](https://about.gitlab.com/handbook/product/ux/product-designer/#deliver).
 - Document user flow and states (for example, using [Mermaid flowcharts in Markdown](../../user/markdown.md#mermaid)).
 - Document animations and transitions.
diff --git a/doc/development/integrations/index.md b/doc/development/integrations/index.md
index 996ba75d463..b51a2799088 100644
--- a/doc/development/integrations/index.md
+++ b/doc/development/integrations/index.md
@@ -10,7 +10,7 @@ description: "GitLab's development guidelines for Integrations"
 This page provides development guidelines for implementing [GitLab integrations](../../user/project/integrations/index.md),
 which are part of our [main Rails project](https://gitlab.com/gitlab-org/gitlab).
 
-Also see our [direction page](https://about.gitlab.com/direction/manage/integrations/) for an overview of our strategy around integrations.
+Also see our [direction page](https://about.gitlab.com/direction/manage/import_and_integrate/integrations/) for an overview of our strategy around integrations.
 
 This guide is a work in progress. You're welcome to ping `@gitlab-org/manage/integrations`
 if you need clarification or spot any outdated information.
diff --git a/doc/development/pipelines/index.md b/doc/development/pipelines/index.md
index 383bc338dc5..7c9340b5571 100644
--- a/doc/development/pipelines/index.md
+++ b/doc/development/pipelines/index.md
@@ -186,8 +186,8 @@ This number can be overridden by setting a CI/CD variable named `RSPEC_FAIL_FAST
 
 ## Re-run previously failed tests in merge request pipelines
 
-In order to reduce the feedback time after resolving failed tests for a merge request, the `rspec rspec-pg13-rerun-previous-failed-tests`
-and `rspec rspec-ee-pg13-rerun-previous-failed-tests` jobs run the failed tests from the previous MR pipeline.
+In order to reduce the feedback time after resolving failed tests for a merge request, the `rspec rspec-pg14-rerun-previous-failed-tests`
+and `rspec rspec-ee-pg14-rerun-previous-failed-tests` jobs run the failed tests from the previous MR pipeline.
 
 This was introduced on August 25th 2021, with <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69053>.
 
@@ -195,7 +195,7 @@ This was introduced on August 25th 2021, with <https://gitlab.com/gitlab-org/git
 
 1. The `detect-previous-failed-tests` job (`prepare` stage) detects the test files associated with failed RSpec
    jobs from the previous MR pipeline.
-1. The `rspec rspec-pg13-rerun-previous-failed-tests` and `rspec rspec-ee-pg13-rerun-previous-failed-tests` jobs
+1. The `rspec rspec-pg14-rerun-previous-failed-tests` and `rspec rspec-ee-pg14-rerun-previous-failed-tests` jobs
    will run the test files gathered by the `detect-previous-failed-tests` job.
 
 ```mermaid
@@ -205,8 +205,8 @@ graph LR
     end
 
     subgraph "test stage";
-        B["rspec rspec-pg13-rerun-previous-failed-tests"];
-        C["rspec rspec-ee-pg13-rerun-previous-failed-tests"];
+        B["rspec rspec-pg14-rerun-previous-failed-tests"];
+        C["rspec rspec-ee-pg14-rerun-previous-failed-tests"];
     end
 
     A --"artifact: list of test files"--> B & C
@@ -625,22 +625,22 @@ This should let us:
 
 ### PostgreSQL versions testing
 
-Our test suite runs against PG13 as GitLab.com runs on PG13 and
-[Omnibus defaults to PG13 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
+Our test suite runs against PostgreSQL 14 as GitLab.com runs on PostgreSQL 14 and
+[Omnibus defaults to PG14 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
 
-We do run our test suite against PG13 on nightly scheduled pipelines.
+We do run our test suite against PostgreSQL 14 on nightly scheduled pipelines.
 
-We also run our test suite against PG13 upon specific database library changes in MRs and `main` pipelines (with the `rspec db-library-code pg13` job).
+We also run our test suite against PostgreSQL 12 and PostgreSQL 13 upon specific database library changes in merge requests and `main` pipelines (with the `rspec db-library-code pg12` and `rspec db-library-code pg13` jobs).
 
 #### Current versions testing
 
 | Where?                                                                                         | PostgreSQL version                              | Ruby version          |
 |------------------------------------------------------------------------------------------------|-------------------------------------------------|-----------------------|
-| Merge requests                                                                                 | 13 (default version), 12 for DB library changes | 3.0 (default version) |
-| `master` branch commits                                                                        | 13 (default version), 12 for DB library changes | 3.0 (default version) |
-| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour)           | 13 (default version), 12 for DB library changes | 3.0 (default version) |
-| `maintenance` scheduled pipelines for the `ruby2` branch (every odd-numbered hour), see below. | 13 (default version), 12 for DB library changes | 2.7                   |
-| `nightly` scheduled pipelines for the `master` branch                                          | 13 (default version), 12, 14 | 3.0 (default version) |
+| Merge requests                                                                                 | 14 (default version), 13 for DB library changes | 3.0 (default version) |
+| `master` branch commits                                                                        | 14 (default version), 13 for DB library changes | 3.0 (default version) |
+| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour)           | 14 (default version), 13 for DB library changes | 3.0 (default version) |
+| `maintenance` scheduled pipelines for the `ruby2` branch (every odd-numbered hour), see below. | 14 (default version), 13 for DB library changes | 2.7                   |
+| `nightly` scheduled pipelines for the `master` branch                                          | 14 (default version), 12, 13, 15                | 3.0 (default version) |
 
 There are 2 pipeline schedules used for testing Ruby 2.7. One is triggering a
 pipeline in `ruby2-sync` branch, which updates the `ruby2` branch with latest
diff --git a/doc/development/pipelines/internals.md b/doc/development/pipelines/internals.md
index 4cdaf50641e..35881db8c6d 100644
--- a/doc/development/pipelines/internals.md
+++ b/doc/development/pipelines/internals.md
@@ -140,6 +140,8 @@ that are scoped to a single [configuration keyword](../../ci/yaml/index.md#job-k
 | `.use-pg13-ee` | Same as `.use-pg13` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
 | `.use-pg14` | Allows a job to use the `postgres` 14, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
 | `.use-pg14-ee` | Same as `.use-pg14` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
+| `.use-pg15` | Allows a job to use the `postgres` 15, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
+| `.use-pg15-ee` | Same as `.use-pg15` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
 | `.use-kaniko` | Allows a job to use the `kaniko` tool to build Docker images. |
 | `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` CI/CD variable. |
 | `.use-docker-in-docker` | Allows a job to use Docker in Docker. |
diff --git a/doc/development/snowplow/implementation.md b/doc/development/snowplow/implementation.md
index 37948f2a3e0..09f617c4ecb 100644
--- a/doc/development/snowplow/implementation.md
+++ b/doc/development/snowplow/implementation.md
@@ -14,7 +14,7 @@ This page describes how to:
 ## Event definitions
 
 Every Snowplow event, regardless of frontend or backend, requires a corresponding event definition. These definitions document the event and its properties to make it easier to maintain and analyze.
-These defintions can be browsed in the [event dictionary](https://metrics.gitlab.com/snowplow). The [event dictionary guide](event_dictionary_guide.md) provides instructions for setting up an event definition.
+These definitions can be browsed in the [event dictionary](https://metrics.gitlab.com/snowplow/). The [event dictionary guide](event_dictionary_guide.md) provides instructions for setting up an event definition.
 
 ## Snowplow JavaScript frontend tracking
 
diff --git a/doc/development/spam_protection_and_captcha/graphql_api.md b/doc/development/spam_protection_and_captcha/graphql_api.md
index 383b52df1fc..5723433203b 100644
--- a/doc/development/spam_protection_and_captcha/graphql_api.md
+++ b/doc/development/spam_protection_and_captcha/graphql_api.md
@@ -16,9 +16,8 @@ related to changing a model's confidential/public flag.
 The main steps are:
 
 1. Use `include Mutations::SpamProtection` in your mutation.
-1. Create a `spam_params` instance based on the request. Obtain the request from the context
-   via `context[:request]` when creating the `SpamParams` instance.
-1. Pass `spam_params` to the relevant Service class constructor.
+1. Pass `perform_spam_check: true` to the Update Service class constructor.
+   It is set to `true` by default in the Create Service.
 1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`
    and pass it the model instance. This call:
    1. Performs the necessary spam checks on the model.
@@ -44,13 +43,10 @@ module Mutations
       include Mutations::SpamProtection
 
       def resolve(args)
-        spam_params = ::Spam::SpamParams.new_from_request(request: context[:request])
-
         service_response = ::Widgets::CreateService.new(
           project: project,
           current_user: current_user,
-          params: args,
-          spam_params: spam_params
+          params: args
         ).execute
 
         widget = service_response.payload[:widget]
diff --git a/doc/development/spam_protection_and_captcha/rest_api.md b/doc/development/spam_protection_and_captcha/rest_api.md
index d7012ffb418..76ffbc2f157 100644
--- a/doc/development/spam_protection_and_captcha/rest_api.md
+++ b/doc/development/spam_protection_and_captcha/rest_api.md
@@ -16,8 +16,8 @@ related to changing a model's confidential/public flag.
 The main steps are:
 
 1. Add `helpers SpammableActions::CaptchaCheck::RestApiActionsSupport` in your `resource`.
-1. Create a `spam_params` instance based on the request.
-1. Pass `spam_params` to the relevant Service class constructor.
+1. Pass `perform_spam_check: true` to the Update Service class constructor.
+   It is set to `true` by default in the Create Service.
 1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`,
    save the created or updated instance in a variable.
 1. Identify the error handling logic for the `failure` case of the request,
@@ -53,8 +53,7 @@ module API
 
       post do
         #...
-        spam_params = ::Spam::SpamParams.new_from_request(request: request)
-        service_response = ::Snippets::CreateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute
+        service_response = ::Snippets::CreateService.new(project: nil, current_user: current_user, params: attrs).execute
         snippet = service_response.payload[:snippet]
 
         if service_response.success?
@@ -71,8 +70,7 @@ module API
 
       put ':id' do
         #...
-        spam_params = ::Spam::SpamParams.new_from_request(request: request)
-        service_response = ::Snippets::UpdateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute(snippet)
+        service_response = ::Snippets::UpdateService.new(project: nil, current_user: current_user, params: attrs, perform_spam_check: true).execute(snippet)
 
         snippet = service_response.payload[:snippet]
 
diff --git a/doc/development/spam_protection_and_captcha/web_ui.md b/doc/development/spam_protection_and_captcha/web_ui.md
index 0ae5e98f399..0cc17854010 100644
--- a/doc/development/spam_protection_and_captcha/web_ui.md
+++ b/doc/development/spam_protection_and_captcha/web_ui.md
@@ -75,11 +75,9 @@ sequenceDiagram
 The backend is also cleanly abstracted via mixin modules and helper methods. The three main
 changes required to the relevant backend controller actions (normally just `create`/`update`) are:
 
-1. Create a `SpamParams` parameter object instance based on the request, using the static
-   `#new_from_request` factory method. This method takes a request, and returns a `SpamParams` instance.
-1. Pass the created `SpamParams` instance as the `spam_params` named argument to the
-   Service class constructor, which you should have already added. If the spam check indicates
-   the changes to the model are possibly spam, then:
+1. Pass `perform_spam_check: true` to the Update Service class constructor.
+   It is set to `true` by default in the Create Service.
+1. If the spam check indicates the changes to the model are possibly spam, then:
    - An error is added to the model.
    - The `needs_recaptcha` property on the model is set to true.
 1. Wrap the existing controller action return value (rendering or redirecting) in a block passed to
@@ -116,12 +114,10 @@ module WidgetsActions
   include SpammableActions::CaptchaCheck::JsonFormatActionsSupport
 
   def create
-    spam_params = ::Spam::SpamParams.new_from_request(request: request)
     widget = ::Widgets::CreateService.new(
       project: project,
       current_user: current_user,
-      params: params,
-      spam_params: spam_params
+      params: params
     ).execute
 
     respond_to do |format|
@@ -166,13 +162,11 @@ class WidgetsController < ApplicationController
 
   def update
     # Existing logic to find the `widget` model instance...
-
-    spam_params = ::Spam::SpamParams.new_from_request(request: request)
     ::Widgets::UpdateService.new(
       project: project,
       current_user: current_user,
       params: params,
-      spam_params: spam_params
+      perform_spam_check: true
     ).execute(widget)
 
     respond_to do |format|
diff --git a/doc/security/hardening.md b/doc/security/hardening.md
new file mode 100644
index 00000000000..21b8594fc6e
--- /dev/null
+++ b/doc/security/hardening.md
@@ -0,0 +1,67 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# GitLab Hardening Recommendations **(FREE SELF)**
+
+This documentation is for GitLab instances where the overall system can be "hardened"
+against common and even not-so-common attacks. It is not designed to completely
+eradicate attacks, but to provide strong mitigation thereby reducing overall risk. Some
+of the techniques apply to any GitLab deployment, such as SaaS or self-managed, while other
+techniques apply to the underlying OS.
+
+These techniques are a work in progress, and have not been tested at scale
+(such as a large environments with many users). They have been tested on a self-managed
+single instance running a Linux package installation, and while many of the techniques can
+translated to other deployment types, they may not all work or apply.
+
+Most of the listed recommendations provide specific recommendations or
+reference choices one can make based upon the general documentation.
+Through hardening, there may be impact to certain features your users may specifically
+want or depend on, so you should communicate with users and do a phased rollout of hardening
+changes.
+
+The hardening instructions are in five categories for easier
+understanding. They are listed in the following section.
+
+## GitLab hardening general concepts
+
+This details information on hardening as an approach to security and some of the larger
+philosophies. For more information, see [hardening general concepts](hardening_general_concepts.md).
+
+## GitLab application settings
+
+Application settings made using the GitLab GUI to the application itself. For more information, see
+[application recommendations](hardening_application_recommendations.md).
+
+## GitLab CI/CD settings
+
+CI/CD is a core component of GitLab, and while application of security principles
+are based upon needs, there are several things you can do to make your CI/CD more secure.
+For more information, see [CI/CD Recommendations](hardening_cicd_recommendations.md).
+
+## GitLab configuration settings
+
+Configuration file settings used to control and configure the
+application (such as `gitlab.rb`) are documented separately. For more information, see the
+[configuration recommendations](hardening_configuration_recommendations.md).
+
+## Operating System settings
+
+You can adjust the underlying operating system to increase overall security. For more information, see the
+[operating system recommendations](hardening_operating_system_recommendations.md).
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_application_recommendations.md b/doc/security/hardening_application_recommendations.md
new file mode 100644
index 00000000000..6ad72569b88
--- /dev/null
+++ b/doc/security/hardening_application_recommendations.md
@@ -0,0 +1,240 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - Application Recommendations
+
+For general hardening guidelines, see the [main hardening documentation](hardening.md).
+
+You control the hardening recommendations for GitLab instances through the
+web interface.
+
+## System hooks
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **System hooks**.
+
+In a typical hardened environment, internal information is not transmitted or stored
+outside of the system. For an offline environment system, this is
+implied. System hooks provide a way for local events in the environment to communicate
+information outside of the environment based upon triggers.
+
+Use cases for this capability are supported, particularly monitoring the
+system through a remote system.
+However, you must apply extreme caution when deploying system hooks. For hardened
+systems, if they are intended to be an offline environment, a perimeter of trusted
+systems allowed to communicate with each other must be enforced, so any hooks
+(system, web, or file) must only communicate with those trusted systems. TLS is strongly
+encouraged for communications through system hooks.
+
+## Push rules
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Push rules**.
+
+Ensure that the following items are selected:
+
+- **Reject unverified users**
+- **Do not allow users to remove Git tags with `git push`**
+- **Check whether the commit author is a GitLab user**
+- **Prevent pushing secret files**
+
+The adjustments help limit pushes to established and authorized users.
+
+## Deploy keys
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Deploy keys**.
+
+Public deploy keys at are used to give read or read/write access to
+**all** projects on the instance, and are intended for remote automation to access
+projects. Public deploy keys should not be used in a hardened environment. If you
+must use deploy keys, use project deploy keys instead. For more information, refer to
+the documentation on [deploy keys](../user/project/deploy_keys/index.md) and
+[project deploy keys](../user/project/deploy_keys/index.md#create-a-project-deploy-key).
+
+## General
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Settings**.
+1. Select **General**.
+
+Hardening adjustments can be made in 4 sections.
+
+### Visibility and access control
+
+The default for the following settings is **Private**:
+
+- **Default project visibility**
+- **Default snippet visibility**
+- **Default group visibility**
+
+Only users that are granted specific access to a project, snippet, or group can
+access these resources. This can be adjusted later as needed or at the time of
+their creation. This helps prevent accidental or malicious disclosure of information.
+
+Depending on your security policy and posture, you might wish to set your
+**Restricted visibility level** to **Public**, as this prevents user profiles
+from being viewed by non-authenticated users.
+
+In **Import sources**, select only the sources you really need.
+
+A typical deployment has **Enabled Git access protocols** set to **Both SSH and HTTP(S)**,
+however if one of the Git protocols is not in use by your users, set it to either
+**Only SSH** or **Only HTTP(S)** accordingly. This helps shrink the attack surface.
+
+For SSH key types, the following are preferred: `ED25519` (and `ED25519-SK`), `RSA`, and
+`ECDSA` (and `ECDSA-SK`) in that order. `ED25519` is considered as secure as `RSA` when
+`RSA` is set to 2048 bits or higher, however the `ED25519` keys are smaller and the
+algorithm is much faster.
+
+`ED25519-SK` and `ECDSA-SK` both end with `-SK` which stands for
+"Security Key". The `-SK` types are compatible with FIDO/U2F standards and pertain to
+usage with hardware tokens, for example YubiKeys.
+
+`DSA` should be set to "Are forbidden". `DSA` has known flaws, and many cryptographers
+are suspicious of and do not support using `ECDSA`.
+
+If GitLab is in FIPS mode, use the following:
+
+- If running in FIPS mode:
+  - Use `RSA`, set to **Must be at least 2048 bits**.
+  - Use `ECDSA` (and `ECDSA-SK`), set to **Must be at least 256 bits**.
+  - Set all other key types to **Are forbidden**.
+  `RSA` and `ECDSA` are both approved for FIPS use.
+- If not running in FIPS mode, you must use `ED25519` and can also use `RSA`:
+  - Set `ED25519` (and `ED25519-SK`) to **Must be at least 256 bits**.
+  - If using `RSA`, set it to **Must be at least 2048 bits**.
+  - Set all other key types to **Are forbidden**.
+- If you are setting up an instance for a new group of users, define your user SSH
+key policy with the maximum bits settings for added security.
+
+In a hardened environment RSS feeds are typically not required, and in **Feed token**,
+select the **Disabled feed token** checkbox.
+
+If all of your users are coming from specific IP addresses, use **Global-allowed IP ranges**
+to specifically allow only those addresses.
+
+For more details on **Visibility and access control**, see [visibility and access controls](../user/admin_area/settings/visibility_and_access_controls.md).
+For information on SSH settings, see
+[SSH keys restrictions](../security/ssh_keys_restrictions.md).
+
+### Account and limit
+
+For hardening purposes, ensure the checkbox next to **Gravatar enabled** is not selected.
+All extraneous communications should be curtailed, and in some environments might be
+restricted. Account avatars can be manually uploaded by users.
+
+The settings in this section are intended to help enforce a custom implementation
+of your own specific standards on your users. As the various scenarios are too many
+and too varied, you should review the
+[account and limit settings documentation](../user/admin_area/settings/account_and_limit_settings.md)
+and apply changes to enforce your own policies.
+
+### Sign-up restrictions
+
+Ensure open sign-up is disabled on your hardened instance. Ensure the **Sign-up enabled** checkbox is not selected.
+
+In **Email confirmation settings**, ensure that **Hard** is selected. User verification
+of their email address is now enforced before access is granted.
+
+The **Minimum password length (number of characters)** default setting is 12 which
+should be fine as long as additional authentication techniques are used. The password
+should be complex, so ensure that all four of these checkboxes are selected:
+
+- **Require numbers**
+- **Require uppercase letters**
+- **Require lowercase letters**
+- **Require symbols**
+
+If all of your users belong to the same organization that uses a specific domain for
+email addresses, then list that domain in **Allowed domains for sign-ups**. This
+prevents those with email addresses in other domains from signing up.
+
+For more detailed information, see
+[sign-up restrictions](../user/admin_area/settings/sign_up_restrictions.md).
+
+### Sign-in restrictions
+
+Two-factor authentication (2FA) should be enabled for all users. Ensure that the
+checkbox next to **Two-factor authentication** (2FA) is selected.
+
+The default setting for **Two-factor grace period** is 48 hours. This should be adjusted
+to a much lower value, such as 8 hours.
+
+Ensure the checkbox next to **Enable admin mode** is selected so that **Admin Mode** is
+active. This requires users with Admin access to have to use additional
+authentication in order to perform administrative tasks, enforcing additional 2FA by the user.
+
+In **Email notification for unknown sign-ins**, ensure that **Enable email notification**
+is selected. This sends an email to users when a sign-in occurs from an unrecognized location.
+
+For more detailed information, see
+[sign-in restrictions](../user/admin_area/settings/sign_in_restrictions.md).
+
+## Integrations
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Settings**.
+1. Select **Integrations**.
+
+In general, as long as administrators control and monitor usage, integrations
+are fine in a hardened environment. Be cautious about integrations that allow
+for actions from an outside system that trigger actions and processes that typically
+require a level of access you would restrict or audit if performed by a local
+process or authenticated user.
+
+## Metrics and profiling
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Settings**.
+1. Under **Integrations**.
+
+The main focus for hardening is **Usage statistics**:
+
+- You should make sure **Enable version check** is selected. This checks to see if you
+are running the latest version of GitLab, and as new versions with new features and
+security patches come out frequently, this helps you stay up to date.
+
+- If your environment is isolated or one where your organizational requirements
+restrict data gathering and statistics reporting to a software vendor, you may have
+to disable the **Enable service ping** feature. For more information on what data is collected to
+help you make an informed decision, see
+[service ping](../development/service_ping/index.md).
+
+## Network
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Settings**.
+1. Under **Network**.
+
+For any setting that enables rate limiting, make sure it is selected. Default values
+should be fine. Additionally there are numerous settings that enable access, and all
+of these should be cleared.
+
+After you've made these adjustments you can fine tune the system to meet performance
+and user needs, which may require disabling and adjusting rate limits or enabling
+accesses. Here are a few notables to keep in mind:
+
+- In **Outbound requests**, if you need to open up access to a limited
+number of systems, you can limit access to just those systems by specifying
+IP address or hostname. Also in this section, make sure you've selected
+**Enforce DNS rebinding attack protection** if you're allowing any access at all.
+
+- Under **Notes rate limit** and **Users API rate limit** you can exclude specific users
+from those limits if needed.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_cicd_recommendations.md b/doc/security/hardening_cicd_recommendations.md
new file mode 100644
index 00000000000..16b649cbdd7
--- /dev/null
+++ b/doc/security/hardening_cicd_recommendations.md
@@ -0,0 +1,69 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - CI/CD Recommendations
+
+General hardening guidelines and philosophies are outlined in the [main hardening documentation](hardening.md).
+
+The hardening recommendations and concepts for CI/CD are listed below.
+
+## Basic Recommendations
+
+How you configure the different CI/CD settings depends on your use of CI/CD. For example if you are using it to build
+packages, you often need real-time access to external resources such as Docker
+images or external code repositories. If you are using it for Infrastructure
+as Code (IaC), you often need to store credentials for external systems to
+automate deployment. For these and many other scenarios, you need to store
+potentially sensitive information to be used during CI/CD operations. As the
+individual scenarios themselves are numerous, we have summarized some basic
+information to help harden the CI/CD process.
+
+- **Secrets Management**. Passwords, tokens, keys, and other secrets that require any
+level of protection should never be stored in plaintext. Some type of encrypted
+container technology should be used, such as GCP Secret Manager, AWS KMS, or
+HashiCorp Vault. For self-managed and standalone instances, HashiCorp Vault is
+recommended, and many GitLab features can take advantage of Vault and are well
+documented in the main [Documentation](../index.md). For detailed CI/CD examples, see [using external secrets in CI](../ci/secrets/index.md).
+- **External Communications**. If your CI/CD process requires connectivity to other
+hosts, ensure that these communication channels are encrypted. You should use TLS 1.2 or 1.3, and where possible implement mutual TLS.
+- **Logging**. Logging can be very important for auditing and troubleshooting, so it
+is important that you enable any logging features to ensure you are getting
+the information in logs you need. Make sure through periodic testing that
+plaintext secrets or other sensitive information is not inadvertently added to log
+files.
+
+## Specific Recommendations
+
+### Pipelines
+
+Pipelines are a part of jobs that execute steps in stages to automate tasks on behalf
+of the users of a project. They are a core component of CD/CD.
+
+By default, only the default branch gets a protected pipeline. An owner of a project
+can ensure that other branches are protected by
+[configuring a protected branch](../user/project/protected_branches.md).
+This allows for more restricted security on pipelines. For more information, see
+[pipeline security on a protected branch](../ci/pipelines/index.md#pipeline-security-on-protected-branches).
+
+Deployment is the part of the CI/CD that deploys the results of the pipeline in
+relationship to a given environment. Default settings do not impose many
+restrictions, and as different users with different roles and responsibilities can
+trigger pipelines that can interact with those environments, you should
+restrict these environments. For more information, see
+[protected environments](../ci/environments/protected_environments.md).
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_configuration_recommendations.md b/doc/security/hardening_configuration_recommendations.md
new file mode 100644
index 00000000000..06a13015633
--- /dev/null
+++ b/doc/security/hardening_configuration_recommendations.md
@@ -0,0 +1,161 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - Configuration Recommendations
+
+General hardening guidelines are outlined in the [main hardening documentation](hardening.md).
+
+Some hardening recommendations for GitLab instances involve additional
+services or control through configuration files. As a reminder, any time you are
+making changes to configuration files, make backup copies of
+them before editing. Additionally, if you are making a lot of changes it is
+recommended you do not do all of the changes at once, and test them after each
+change to ensure everything is working.
+
+## NGINX
+
+NGINX is used to serve up the web interface used to access the GitLab instance. As
+NGINX is controlled and integrated into GitLab, modification of the
+`/etc/gitlab/gitlab.rb` file used for adjustments. Here are a few recommendations for helping to improve
+the security of NGINX itself:
+
+```shell
+#
+# Only strong ciphers are used
+#
+nginx['ssl_ciphers'] = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256"
+#
+# Follow preferred ciphers and the order listed as preference
+#
+nginx['ssl_prefer_server_ciphers'] = "on"
+#
+# Only allow TLSv1.2 and TLSv1.3
+#
+nginx['ssl_protocols'] = "TLSv1.2 TLSv1.3"
+
+##! **Recommended in: https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
+nginx['ssl_session_cache'] = "builtin:1000  shared:SSL:10m"
+
+##! **Default according to https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
+nginx['ssl_session_timeout'] = "5m"
+
+# Should prevent logjam attack etc
+# For the example below, run the following first:
+# openssl dhparam -out /etc/gitlab/ssl/dhparam.pem 4096
+nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem" # changed from nil
+
+# Turn off session ticket reuse
+nginx['ssl_session_tickets'] = "off"
+# Pick our own curve instead of what openssl hands us
+nginx['ssl_ecdh_curve'] = "secp384r1"
+```
+
+## Consul
+
+Consul can be integrated into a GitLab environment, and is intended for larger
+deployments. In general for self-managed and standalone deployments with less than
+1000 users, Consul may not be needed. If it is needed, first review the
+[documentation on Consul](../administration/consul.md), but
+more importantly ensure that encryption is used during communications. For more
+detailed information on Consul visit the
+[HashiCorp website](https://developer.hashicorp.com/consul/docs) to understand how it
+works, and review the information on
+[encryption security](https://developer.hashicorp.com/consul/docs/security/encryption).
+
+## Environment Variables
+
+You can customize multiple
+[environment variables](https://docs.gitlab.com/omnibus/settings/environment-variables.md)
+on self-managed systems. The main environment variable to
+take advantage of from a security perspective is `GITLAB_ROOT_PASSWORD` during the
+installation process. If you are installing the self-managed system with a
+public-facing IP address exposed to the Internet, make sure the password is set to
+something strong. Historically, setting up any type of public-facing service - whether
+it is GitLab or some other application - has shown that opportunistic attacks occur
+as soon as those systems are discovered, so the hardening process should start during
+the installation process.
+
+As mentioned in the [operating system recommendations](hardening_operating_system_recommendations.md)
+ideally there should be firewall rules already in place before the GitLab
+installation begins, but you should still set a secure password before the
+installation through `GITLAB_ROOT_PASSWORD`.
+
+## Git Protocols
+
+To ensure that only authorized users are using SSH for Git access, add the following
+to your `/etc/ssh/sshd_config` file:
+
+```shell
+# Ensure only authorized users are using Git
+AcceptEnv GIT_PROTOCOL
+```
+
+This ensures that users cannot pull down projects using SSH unless they have a valid
+GitLab account that can perform `git` operations over SSH. More details can be found
+under [Configuring Git Protocol](../administration/git_protocol.md).
+
+## Incoming Email
+
+You can configure a GitLab self-managed instance to allow for incoming email to be
+used for commenting or creating issues and merge requests by registered users on
+the GitLab instance. In a hardened environment you should not configure
+this feature as it involves outside communications sending in information.
+
+If the feature is required, follow the instructions in the
+[incoming email documentation](../administration/incoming_email.md), with
+the following recommendations to ensure maximum security:
+
+- Dedicate an email address specifically for inbound emails to the instance.
+- Use [email sub-addressing](../administration/incoming_email.md).
+- Email accounts used by users to send emails should require and have multi-factor authentication (MFA) enabled on those accounts.
+- For Postfix specifically, follow the [set up Postfix for incoming email documentation](../administration/reply_by_email_postfix_setup.md).
+
+## Redis Replication and Failover
+
+Redis is used on a Linux package installation for replication and failover, and can be
+set up when scaling requires that capability. Bear in mind that this opens TCP ports
+`6379` for Redis and `26379` for Sentinel. Follow the
+[replication and failover documentation](../administration/redis/replication_and_failover.md)
+but note the IP addresses of all of the nodes, and set up firewall rules between
+nodes that only allow the other node to access those particular ports.
+
+## Sidekiq Configuration
+
+In the [instructions for configuring an external Sidekiq](../administration/sidekiq/index.md)
+there are numerous references to configuring IP ranges. You must
+[configure HTTPS](../administration/sidekiq/index.md#enable-https),
+and consider restricting those IP addresses to specific systems that Sidekiq talks to.
+You might have to adjust firewall rules at the operating system level as well.
+
+## S/MIME Signing of Email
+
+If the GitLab instance is configured for sending out email notifications to users,
+configure S/MIME signing to help the recipients ensure that the emails are
+legitimate. Follow the instructions on [signing outgoing email](../administration/smime_signing_email.md).
+
+## Container Registry
+
+If Lets Encrypt is configured, the Container Registry is enabled by default. This
+allows projects to store their own Docker images. Follow the instructions for
+configuring the [Container Registry](../administration/packages/container_registry.md),
+so you can do things like restrict automatic enablement on new projects and
+disabling the Container Registry entirely. You may have to adjust firewall rules to
+allow access - if a completely standalone system, you should restrict access to the
+Container Registry to localhost only. Specific examples of ports used and their
+configuration are also included in the documentation.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_general_concepts.md b/doc/security/hardening_general_concepts.md
new file mode 100644
index 00000000000..a227f0134d0
--- /dev/null
+++ b/doc/security/hardening_general_concepts.md
@@ -0,0 +1,88 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - General Concepts
+
+General hardening guidelines are outlined in the [main hardening documentation](hardening.md).
+
+The following documentation summarises some of the underlying philosophies for GitLab instance hardening.
+While we reference GitLab, in many cases they can actually apply to all computer systems.
+
+## Layered security
+
+If there are two ways to implement security, both ways should be implemented instead of
+just one. A quick example is account security:
+
+- Use a long, complex, and unique password for the account.
+- Implement a second factor to the authentication process for added security.
+- Use a hardware token as a second factor.
+- Lock out an account (for at least a fixed amount of time) for failed authentication
+attempts.
+- An account that is unused for a specific time frame should be disabled, enforce this
+with either automation or regular audits.
+
+Instead of using only one or two items on the list, use as many as possible. This
+philosophy can apply to other areas besides account security - it should be applied to
+every area possible.
+
+## Eliminate security through obscurity
+
+Security through obscurity means that one does not discuss certain
+elements of a system, service, or process because of a fear that a potential attacker
+might use those details to formulate an attack. Instead, the system should be secured to
+the point that details about its configuration could be public and the system would still
+be as secure as it could be. In essence, if an attacker learned about the details of the
+configuration of a computer system it would not give them an advantage. One of the
+downsides of security through obscurity is that it can lead to a potential false sense of
+security by the administrator of the system who thinks the system is more secure than it
+actually is.
+
+An example of this is running a service on a non-standard TCP port. For example the
+default SSH daemon port on servers is TCP port 22, but it is possible to configure the
+SSH daemon to run on another port such as TCP port 2222. The administrator who configured
+this might think it increases the security of the system, however it is quite common for
+an attacker to port scan a system to discover all open ports, allowing for quick discovery
+of the SSH service, and eliminating any perceived security advantage.
+
+As GitLab is an open-core system and all of the configuration options are well documented
+and public information, the idea of security through obscurity goes against a
+GitLab core value - transparency. These hardening recommendations are intended to be
+public, to help eliminate any security through obscurity.
+
+## Attack Surface Reduction
+
+GitLab is a large system with many components. As a general rule for security, it helps
+if unused systems are disabled. This eliminates the
+available "attack surface" a potential attacker can use to strike. This can also have
+the added advantage of increasing available system resources as well.
+
+As an example, there is a process on a system that fires up and checks queues for input every
+five minutes, querying multiple sub-processes while performing its checks. If you are not
+using that process, there is no reason to have it configured and it should be disabled.
+If an attacker has figured out an attack vector that uses this process, the attacker might exploit it despite your organization not using it. As a general
+rule, you should disable any service not being used.
+
+## External systems
+
+In larger but still hardened deployments, multiple nodes are often used to
+handle the load your GitLab deployment
+requires. In those cases, use a combination of external, operating system, and
+configuration options for firewall rules. Any option that uses restrictions should only
+be opened up enough to allow the subsystem to function. Whenever possible use TLS
+encryption for network traffic.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/hardening_operating_system_recommendations.md b/doc/security/hardening_operating_system_recommendations.md
new file mode 100644
index 00000000000..8b4b706815c
--- /dev/null
+++ b/doc/security/hardening_operating_system_recommendations.md
@@ -0,0 +1,167 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Hardening - Operating System Recommendations
+
+General hardening guidelines are outlined in the [main hardening documentation](hardening.md).
+
+You can configure the underlying operating system to increase overall security. In a
+a controlled environment such as a self-managed GitLab instance it requires additional
+steps, and in fact is often required for certain deployments. FedRAMP is an example of
+such a deployment.
+
+## SSH Configuration
+
+### SSH Client Configuration
+
+For client access (either to the GitLab instance or to the underlying operating
+system), here are a couple of recommendations for SSH key generation. The first one
+is a typical SSH key:
+
+```shell
+ssh-keygen -a 64 -t ed25519 -f ~/.ssh/id_ed25519 -C "ED25519 Key"
+```
+
+For a FIPS-compliant SSH key, use the following:
+
+```shell
+ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "RSA FIPS-compliant Key"
+```
+
+### SSH Server Configuration
+
+At the operating system level, if you are allowing SSH access (typically through
+OpenSSH), here is an example of configuration options for the `sshd_config` file
+(the exact location may vary depending on the operating system but it is usually
+`/etc/ssh/sshd_config`):
+
+```shell
+#
+# Example sshd config file. This supports public key authentication and
+# turns off several potential security risk areas
+#
+PubkeyAuthentication yes
+PasswordAuthentication yes
+UsePAM yes
+UseDNS no
+AllowTcpForwarding no
+X11Forwarding no
+PrintMotd no
+PermitTunnel no
+# Allow client to pass locale environment variables
+AcceptEnv LANG LC_*
+# override default of no subsystems
+Subsystem       sftp    /usr/lib/openssh/sftp-server
+# Protocol adjustments, these would be needed/recommended in a FIPS or
+# FedRAMP deployment, and use only strong and proven algorithm choices
+Protocol 2
+Ciphers aes128-ctr,aes192-ctr,aes256-ctr
+HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
+KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
+Macs hmac-sha2-256,hmac-sha2-512
+
+```
+
+## Firewall Rules
+
+For firewall rules, only TCP ports `80` and `443` need to be open for basic usage. By
+default, `5050` is open for remote access to the container registry, however in a
+hardened environment this would most likely exist on a different host, and in some
+environments not open at all. Hence, the recommendation is for ports `80` and `443`
+only, and port `80` should only be used to redirect to `443`.
+
+For a truly hardened or isolated environment such as FedRAMP, you should adjust the firewall rules to restrict all ports except to those networks
+accessing it. For example, if the IP address is `192.168.1.2` and all of the authorized
+clients are also on `192.168.1.0/24`, restrict access to ports `80` and `443` to just
+`192.168.1.0/24` only (as a safety restriction), even if access is restricted
+elsewhere with another firewall.
+
+Ideally, if you're installing a self-managed instance, you should implement the firewall rules before the installation begins with access restricted to the admins and installers, and only add additional ranges of IP addresses for
+users after the instance is installed and properly hardened.
+
+Usage of `iptables` or `ufw` is acceptable to implement and enforce port `80` and `443`
+access on a per-host basis, otherwise usage of cloud-based firewall rules through GCP
+Google Compute or AWS Security Groups should enforce this. All other ports should
+be blocked, or at least restricted to specific ranges. For more information on ports, see
+[Package Defaults](../administration/package_information/defaults.md).
+
+### Firewall Additions
+
+It is possible that various services may be enabled that require external access
+(for example Sidekiq) and need network access to be opened up. Restrict these types
+of services to specific IP addresses, or a specific Class C. As a layered and added
+precaution, where possible restrict these extra services to specific nodes or
+sub-networks in GitLab.
+
+## Kernel Adjustments
+
+Kernel adjustments can be made by editing `/etc/sysctl.conf`, or one of the files in
+`/etc/sysctl.d/`. Kernel adjustments do not completely eliminate the threat of an
+attack, but add an extra layer of security. The following notes explain
+some of the advantages for these adjustments.
+
+```shell
+## Kernel tweaks for sysctl.conf ##
+##
+## The following help mitigate out of bounds, null pointer dereference, heap and
+## buffer overflow bugs, use-after-free etc from being exploited. It does not 100%
+## fix the issues, but seriously hampers exploitation.
+##
+# Default is 65536, 4096 helps mitigate memory issues used in exploitation
+vm.mmap_min_addr=4096
+# Default is 0, randomize virtual address space in memory, makes vuln exploitation
+# harder
+kernel.randomize_va_space=2
+# Restrict kernel pointer access (e.g. cat /proc/kallsyms) for exploit assistance
+kernel.kptr_restrict=2
+# Restrict verbose kernel errors in dmesg
+kernel.dmesg_restrict=1
+# Restrict eBPF
+kernel.unprivileged_bpf_disabled=1
+net.core.bpf_jit_harden=2
+# Prevent common use-after-free exploits
+vm.unprivileged_userfaultfd=0
+
+## Networking tweaks ##
+##
+## Prevent common attacks at the IP stack layer
+##
+# Prevent SYNFLOOD denial of service attacks
+net.ipv4.tcp_syncookies=1
+# Prevent time wait assassination attacks
+net.ipv4.tcp_rfc1337=1
+# IP spoofing/source routing protection
+net.ipv4.conf.all.rp_filter=1
+net.ipv4.conf.default.rp_filter=1
+net.ipv6.conf.all.accept_ra=0
+net.ipv6.conf.default.accept_ra=0
+net.ipv4.conf.all.accept_source_route=0
+net.ipv4.conf.default.accept_source_route=0
+net.ipv6.conf.all.accept_source_route=0
+net.ipv6.conf.default.accept_source_route=0
+# IP redirection protection
+net.ipv4.conf.all.accept_redirects=0
+net.ipv4.conf.default.accept_redirects=0
+net.ipv4.conf.all.secure_redirects=0
+net.ipv4.conf.default.secure_redirects=0
+net.ipv6.conf.all.accept_redirects=0
+net.ipv6.conf.default.accept_redirects=0
+net.ipv4.conf.all.send_redirects=0
+net.ipv4.conf.default.send_redirects=0
+```
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/security/index.md b/doc/security/index.md
index 7a78461d717..a62d7171112 100644
--- a/doc/security/index.md
+++ b/doc/security/index.md
@@ -27,6 +27,6 @@ type: index
 - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
 - [Responding to security incidents](responding_to_security_incidents.md)
 
-To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md) .
+To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md). For more detailed information, refer to [Hardening](hardening.md).
 
 Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index bc96768bbd1..c3593d0b986 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -16,7 +16,7 @@ You don't need to install anything to use GitLab SaaS, you only need to
 
 The subscription determines which features are available for your private projects. Organizations with public open source projects can actively apply to our [GitLab for Open Source Program](https://about.gitlab.com/solutions/open-source/join/).
 
-Qualifying open source projects also get 50,000 CI/CD minutes and free access to the **Ultimate** tier
+Qualifying open source projects also get 50,000 units of compute and free access to the **Ultimate** tier
 through the [GitLab for Open Source program](https://about.gitlab.com/solutions/open-source/).
 
 ## Obtain a GitLab SaaS subscription
@@ -355,18 +355,18 @@ To change the contacts:
    [these requirements](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/customersdot/associating_purchases.html).
 1. [Create a ticket with the Support team](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293). Include any relevant material in your request.
 
-## CI/CD minutes
+## Compute
 
-CI/CD minutes are the execution time for your [pipelines](../../ci/pipelines/index.md)
+Compute is the resource consumed when running [pipelines](../../ci/pipelines/index.md)
 on GitLab shared runners.
 
-Refer to [CI/CD minutes](../../ci/pipelines/cicd_minutes.md)
+Refer to [Compute usage](../../ci/pipelines/cicd_minutes.md)
 for more information.
 
-### Purchase additional CI/CD minutes
+### Purchase additional units of compute
 
-You can [purchase additional minutes](../../ci/pipelines/cicd_minutes.md#purchase-additional-cicd-minutes)
-for your personal or group namespace. CI/CD minutes are a **one-time purchase**, so they do not renew.
+You can [purchase additional units of compute](../../ci/pipelines/cicd_minutes.md#purchase-additional-units-of-compute)
+for your personal or group namespace. Units of compute are a **one-time purchase**, so they do not renew.
 
 ## Add-on subscription for additional Storage and Transfer
 
diff --git a/doc/user/application_security/policies/scan-result-policies.md b/doc/user/application_security/policies/scan-result-policies.md
index ecbbf4703b0..d8cd984ad40 100644
--- a/doc/user/application_security/policies/scan-result-policies.md
+++ b/doc/user/application_security/policies/scan-result-policies.md
@@ -15,6 +15,9 @@ findings of one or more security scan jobs. Scan result policies are evaluated a
 NOTE:
 Scan result policies are applicable only to [protected](../../project/protected_branches.md) target branches.
 
+NOTE:
+When a protected branch is created or deleted, the policy approval rules synchronize, with a delay of 1 minute.
+
 The following video gives you an overview of GitLab scan result policies:
 
 <div class="video-fallback">
diff --git a/doc/user/group/saml_sso/group_sync.md b/doc/user/group/saml_sso/group_sync.md
index ee59eeb98db..430f2c4a69f 100644
--- a/doc/user/group/saml_sso/group_sync.md
+++ b/doc/user/group/saml_sso/group_sync.md
@@ -225,7 +225,7 @@ in the user's SAML assertion.
 With an Azure AD premium subscription, you can allow up to 500 group IDs to be sent in a SAML token using the
 [Azure AD documentation configuration steps](https://support.esri.com/en/technical-article/000022190).
 
-Otherwise, you can work around this issue by changing the [group claims](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims#configure-the-azure-ad-application-registration-for-group-attributes) to use the `Groups assigned to the application` option instead.
+Otherwise, you can work around this issue by changing the [group claims](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-connect-fed-group-claims#configure-the-azure-ad-application-registration-for-group-attributes) to use the `Groups assigned to the application` option instead.
 
 ![Manage Group Claims](img/Azure-manage-group-claims.png).
 
diff --git a/doc/user/project/settings/project_access_tokens.md b/doc/user/project/settings/project_access_tokens.md
index ff3a581638f..b0554b80b4c 100644
--- a/doc/user/project/settings/project_access_tokens.md
+++ b/doc/user/project/settings/project_access_tokens.md
@@ -11,6 +11,7 @@ type: reference, howto
 > - [Became available on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/235765) in GitLab 13.5 for paid groups only.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235765) in GitLab 13.5.
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/342327) in GitLab 14.5. Default prefix added.
+> - [Became available in trial subscriptions](https://gitlab.com/gitlab-org/gitlab/-/issues/386041) in GitLab 16.1. Default prefix added.
 
 Project access tokens are similar to passwords, except you can [limit access to resources](#scopes-for-a-project-access-token),
 select a limited role, and provide an expiry date.
@@ -32,7 +33,7 @@ The ability to create project access tokens without expiry was [deprecated](http
 
 You can use project access tokens:
 
-- On GitLab SaaS: If you have the Premium or Ultimate license tier. Only one project access token is available with a [trial license](https://about.gitlab.com/free-trial/).
+- On GitLab SaaS: If you have the Premium or Ultimate license tier, only one project access token is available with a [trial license](https://about.gitlab.com/free-trial/).
 - On self-managed instances of GitLab: With any license tier. If you have the Free tier:
   - Review your security and compliance policies around
     [user self-enrollment](../../admin_area/settings/sign_up_restrictions.md#disable-new-sign-ups).
@@ -139,4 +140,4 @@ See also [Bot users for groups](../../group/settings/group_access_tokens.md#bot-
 
 ## Token availability
 
-More than one project access token is only available in paid subscriptions, and only one is available in trial subscriptions. For more information, see the ["What is included" section of the GitLab Trial FAQ](https://about.gitlab.com/free-trial/#what-is-included-in-my-free-trial-what-is-excluded).
+More than one project access token is only available in paid subscriptions. In Premium and Ultimate trial subscriptions, only one project access token is included. For more information, see the ["What is included" section of the GitLab Trial FAQ](https://about.gitlab.com/free-trial/#what-is-included-in-my-free-trial-what-is-excluded).