Add latest changes from gitlab-org/gitlab@14-10-stable-eev14.10.0-rc42

6 files changed, 73 insertions, 7 deletions

diff --git a/doc/security/index.md b/doc/security/index.md
index da3fa761f3f..73ac5028db5 100644
--- a/doc/security/index.md
+++ b/doc/security/index.md
@@ -26,6 +26,7 @@ type: index
 - [CI/CD variables](../ci/variables/index.md#cicd-variable-security)
 - [Token overview](token_overview.md)
 - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
+- [Responding to security incidents](responding_to_security_incidents.md)
 
 ## Securing your GitLab installation
 
diff --git a/doc/security/reset_user_password.md b/doc/security/reset_user_password.md
index 1940c5be73a..06934b187c1 100644
--- a/doc/security/reset_user_password.md
+++ b/doc/security/reset_user_password.md
@@ -74,11 +74,13 @@ If you know the username, user ID, or email address, you can use the Rails conso
      user = User.find_by(email: 'user@example.com')
      ```
 
-1. Reset the password:
+1. Reset the password by setting a value for `user.password` and `user.password_confirmation`. For example, to set a new random
+   password:
 
    ```ruby
-   user.password = 'secret_pass'
-   user.password_confirmation = 'secret_pass'
+   new_password = ::User.random_password
+   user.password = new_password
+   user.password_confirmation = new_password
     ```
 
 1. Optional. Notify the user that an administrator changed their password:
diff --git a/doc/security/responding_to_security_incidents.md b/doc/security/responding_to_security_incidents.md
new file mode 100644
index 00000000000..b3bce785695
--- /dev/null
+++ b/doc/security/responding_to_security_incidents.md
@@ -0,0 +1,65 @@
+---
+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/engineering/ux/technical-writing/#assignments
+type: reference, howto
+---
+
+# Responding to security incidents **(FREE SELF)**
+
+When a security incident occurs, you should follow the processes defined by your organization. However, you might consider some
+additional steps. These suggestions are intended to supplement existing security incident response processes within your organization.
+
+## Suspected compromised user account
+
+If you suspect that a user account or bot account has been compromised, consider taking the following steps:
+
+- [Block the user](../user/admin_area/moderate_users.md#block-a-user) to mitigate any current risk.
+- [Review the audit events](../administration/audit_events.md) available to you to identify any suspicious account behavior. For
+  example:
+  - Suspicious sign-in events.
+  - Creation or deletion of personal access tokens, project access tokens, and group access tokens.
+  - Creation or deletion of SSH or GPG keys.
+  - Creation, modification, or deletion of two-factor authentication.
+  - Changes to repositories.
+  - Changes to group or project configurations.
+  - Addition or modification of runners.
+  - Addition or modification of webhooks or Git hooks.
+- Reset any credentials the user might have had access to. For example, users with at least the Maintainer role can view protected
+  [CI/CD variables](../ci/variables/index.md) and [runner registration tokens](token_overview.md#runner-registration-tokens).
+- [Reset the user's password](reset_user_password.md).
+- Get the user to [enable two factor authentication](../user/profile/account/two_factor_authentication.md) (2FA), and consider [enforcing 2FA at the instance or group level](two_factor_authentication.md)
+- After completing an investigation and mitigating impacts, unblock the user.
+
+## Suspected compromised instance **(FREE SELF)**
+
+Self-managed GitLab customers and administrators are responsible for:
+
+- The security of their underlying hosts.
+- Keeping GitLab itself up to date.
+
+It is important to [regularly update GitLab](../policy/maintenance.md), update your operating system and its software, and harden your
+hosts in accordance with vendor guidance.
+
+If you suspect that your GitLab instance has been compromised, consider taking the following steps:
+
+- [Review the audit events](../administration/audit_events.md) available to you for suspicious account behavior.
+- [Review all users](../user/admin_area/moderate_users.md) (including the Administrative root user), and follow the steps in [Suspected compromised user account](#suspected-compromised-user-account) if necessary.
+- Review the [Credentials Inventory](../user/admin_area/credentials_inventory.md), if available to you.
+- Change any sensitive credentials, variables, tokens, and secrets. For example, those located in instance configuration, database,
+  CI/CD pipelines, or elsewhere.
+- Upgrade to the latest version of GitLab and adopt a plan to upgrade after every security patch release.
+
+In addition, the suggestions below are common steps taken in incident response plans when servers are compromised by malicious actors.
+
+WARNING:
+Use these suggestions at your own risk.
+
+- Save any server state and logs to a write-once location, for later investigation.
+- Look for unrecognized background processes.
+- Check for open ports on the system.
+- Rebuild the host from a known-good backup or from scratch, and apply all the latest security patches.
+- Review network logs for uncommon traffic.
+- Establish network monitoring and network-level controls.
+- Restrict inbound and outbound network access to authorized users and servers only.
+- Ensure all logs are routed to an independent write-only datastore.
diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md
index 2e4a737f9aa..03bc0207cf5 100644
--- a/doc/security/ssh_keys_restrictions.md
+++ b/doc/security/ssh_keys_restrictions.md
@@ -39,7 +39,7 @@ Hovering over this icon tells you why the key is restricted.
 ## Default settings
 
 By default, the GitLab.com and self-managed settings for the
-[supported key types](../ssh/index.md#supported-ssh-key-types) are:
+[supported key types](../user/ssh.md#supported-ssh-key-types) are:
 
 - RSA SSH keys are allowed.
 - DSA SSH keys are forbidden ([since GitLab 11.0](https://about.gitlab.com/releases/2018/06/22/gitlab-11-0-released/#support-for-dsa-ssh-keys)).
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index cab9f6a957e..ae13881fe6f 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -114,7 +114,7 @@ FLAG:
 On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. The feature is not ready for production use. This feature flag also affects [session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
 
 Two-factor authentication can be enforced for Git over SSH operations. However, we recommend using
-[ED25519_SK](../ssh/index.md#ed25519_sk-ssh-keys) or [ECDSA_SK](../ssh/index.md#ecdsa_sk-ssh-keys) SSH keys instead.
+[ED25519_SK](../user/ssh.md#ed25519_sk-ssh-keys) or [ECDSA_SK](../user/ssh.md#ecdsa_sk-ssh-keys) SSH keys instead.
 
 The one-time password (OTP) verification can be done using a command:
 
diff --git a/doc/security/user_file_uploads.md b/doc/security/user_file_uploads.md
index e8b0c08e240..dcdd18a9f0b 100644
--- a/doc/security/user_file_uploads.md
+++ b/doc/security/user_file_uploads.md
@@ -7,8 +7,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # User File Uploads **(FREE)**
 
-> - In GitLab 14.8 and later, [authorization checks are enforced](https://gitlab.com/gitlab-org/gitlab/-/issues/26781) on media uploads. This change is being [rolled out incrementally](https://gitlab.com/gitlab-org/gitlab/-/issues/352291) on GitLab.com in 14.9.
-
 Images that are attached to issues, merge requests, or comments
 do not require authentication to be viewed if they are accessed directly by URL.
 This direct URL contains a random 32-character ID that prevents unauthorized