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

4 files changed, 59 insertions, 28 deletions

diff --git a/doc/security/password_storage.md b/doc/security/password_storage.md
index b4c2e27c952..d3db8cbe4f6 100644
--- a/doc/security/password_storage.md
+++ b/doc/security/password_storage.md
@@ -7,18 +7,32 @@ type: reference
 
 # Password storage **(FREE)**
 
+> PBKDF2 and SHA512 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360658) in GitLab 15.2 [with flags](../administration/feature_flags.md) named `pbkdf2_password_encryption` and `pbkdf2_password_encryption_write`. Disabled by default.
+
 GitLab stores user passwords in a hashed format to prevent passwords from being
 stored as plain text.
 
 GitLab uses the [Devise](https://github.com/heartcombo/devise) authentication
 library to hash user passwords. Created password hashes have these attributes:
 
-- **Hashing**: The [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing
-  function is used to generate the hash of the provided password. This is a
-  strong, industry-standard cryptographic hashing function.
+- **Hashing**:
+  - **BCrypt**: By default, the [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing
+    function is used to generate the hash of the provided password. This is a
+    strong, industry-standard cryptographic hashing function.
+  - **PBKDF2 and SHA512**: Starting in GitLab 15.2, PBKDF2 and SHA512 are supported
+    behind the following feature flags (disabled by default):
+    - `pbkdf2_password_encryption` - Enables reading and comparison of PBKDF2 + SHA512
+      hashed passwords and supports fallback for BCrypt hashed passwords.
+    - `pbkdf2_password_encryption_write` - Enables new passwords to be saved
+      using PBKDF2 and SHA512, and existing BCrypt passwords to be migrated when users sign in.
+
+    FLAG:
+    On self-managed GitLab, by default this feature is not available. To make it available,
+    ask an administrator to [enable the feature flags](../administration/feature_flags.md) named `pbkdf2_password_encryption` and `pbkdf2_password_encryption_write`.
+
 - **Stretching**: Password hashes are [stretched](https://en.wikipedia.org/wiki/Key_stretching)
   to harden against brute-force attacks. By default, GitLab uses a stretching
-  factor of 10.
+  factor of 10 for BCrypt and 20,000 for PBKDF2 + SHA512.
 - **Salting**: A [cryptographic salt](https://en.wikipedia.org/wiki/Salt_(cryptography))
   is added to each password to harden against pre-computed hash and dictionary
   attacks. To increase security, each salt is randomly generated for each
diff --git a/doc/security/rate_limits.md b/doc/security/rate_limits.md
index 695a0d52af6..e48a9999a06 100644
--- a/doc/security/rate_limits.md
+++ b/doc/security/rate_limits.md
@@ -43,6 +43,7 @@ You can set these rate limits in the Admin Area of your instance:
 - [Deprecated API rate limits](../user/admin_area/settings/deprecated_api_rate_limits.md)
 - [GitLab Pages rate limits](../administration/pages/index.md#rate-limits)
 - [Pipeline rate limits](../user/admin_area/settings/rate_limit_on_pipelines_creation.md)
+- [Incident management rate limits](../user/admin_area/settings/incident_management_rate_limits.md)
 
 You can set these rate limits using the Rails console:
 
diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md
index eb92694d236..eca52c41e4f 100644
--- a/doc/security/ssh_keys_restrictions.md
+++ b/doc/security/ssh_keys_restrictions.md
@@ -48,14 +48,10 @@ By default, the GitLab.com and self-managed settings for the
 - ECDSA_SK SSH keys are allowed (GitLab 14.8 and later).
 - ED25519_SK SSH keys are allowed (GitLab 14.8 and later).
 
-### Block banned or compromised keys **(FREE)**
+## Block banned or compromised keys **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24614) in GitLab 15.1 [with a flag](../administration/feature_flags.md) named `ssh_banned_key`. Enabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature per user,
-ask an administrator to [disable the feature flag](../administration/feature_flags.md) named `ssh_banned_key`.
-On GitLab.com, this feature is available.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24614) in GitLab 15.1 [with a flag](../administration/feature_flags.md) named `ssh_banned_key`. Enabled by default.
+> - Generally available in GitLab 15.2. [Feature flag `ssh_banned_key`](https://gitlab.com/gitlab-org/gitlab/-/issues/363410) removed.
 
 When users attempt to [add a new SSH key](../user/ssh.md#add-an-ssh-key-to-your-gitlab-account)
 to GitLab accounts, the key is checked against a list of SSH keys which are known
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index ae13881fe6f..5907860f5cc 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -5,7 +5,7 @@ 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
 ---
 
-# Enforce two-factor authentication **(FREE SELF)**
+# Enforce two-factor authentication **(FREE)**
 
 Two-factor authentication (2FA) provides an additional level of security to your
 users' GitLab account. When enabled, users are prompted for a code generated by an application in
@@ -13,7 +13,7 @@ addition to supplying their username and password to sign in.
 
 Read more about [two-factor authentication (2FA)](../user/profile/account/two_factor_authentication.md)
 
-## Enforce 2FA for all users
+## Enforce 2FA for all users **(FREE SELF)**
 
 Users on GitLab can enable it without any administrator's intervention. If you
 want to enforce everyone to set up 2FA, you can choose from two different ways:
@@ -33,7 +33,7 @@ To enable 2FA for all users:
 If you want 2FA enforcement to take effect during the next sign-in attempt,
 change the grace period to `0`.
 
-## Disable 2FA enforcement through Rails console
+### Disable 2FA enforcement through Rails console
 
 Using the [Rails console](../administration/operations/rails_console.md), enforcing 2FA for
 all user can be disabled. Connect to the Rails console and run:
@@ -46,19 +46,22 @@ Gitlab::CurrentSettings.update!('require_two_factor_authentication': false)
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) in GitLab 12.0, 2FA settings for a group are also applied to subgroups.
 
-To enforce 2FA only for certain groups:
+Prerequisites:
+
+- You must have the Maintainer or Owner role for the group.
 
-1. Go to the group's **Settings > General** page.
-1. Expand the **Permissions and group features** section.
-1. Select the **Require all users in this group to set up two-factor authentication** option.
+To enforce 2FA only for certain groups:
 
-You can also specify a grace period in the **Time before enforced** option.
+1. On the top bar, select **Menu > Groups** and find your group.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Permissions and group features**.
+1. Select **All users in this group must set up two-factor authentication**.
+1. Select **Save changes**.
 
-To change this setting, you must be an administrator or owner of the group.
+You can also specify a grace period in the **Delay 2FA enforcement** option.
 
 If you want to enforce 2FA only for certain groups, you can enable it in the
-group settings and specify a grace period as above. To change this setting you
-must be administrator or owner of the group.
+group settings and specify a grace period as above.
 
 The following are important notes about 2FA:
 
@@ -80,15 +83,36 @@ The following are important notes about 2FA:
   1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field.
 
   This action causes all subgroups with 2FA requirements to stop requiring that from their members.
+- Access tokens are not required to provide a second factor for authentication because they are API-based.
+  Tokens generated before 2FA is enforced remain valid.
 
-## Disable 2FA for everyone
+## Disable 2FA **(FREE SELF)**
 
 WARNING:
-Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforce-2fa-for-all-users)
+Disabling 2FA for users does not disable the [enforce 2FA for all users](#enforce-2fa-for-all-users)
 or [enforce 2FA for all users in a group](#enforce-2fa-for-all-users-in-a-group)
 settings. You must also disable any enforced 2FA settings so users aren't asked to set up 2FA again
 when they next sign in to GitLab.
 
+WARNING:
+This is a permanent and irreversible action. Users must reactivate 2FA to use it again.
+
+### For a single user
+
+To disable 2FA for non-administrator users, we recommend using the [API endpoint](../api/users.md#disable-two-factor-authentication)
+instead of the Rails console.
+Using the [Rails console](../administration/operations/rails_console.md), 2FA for a single user can be disabled.
+Connect to the Rails console and run:
+
+```ruby
+admin = User.find_by_username('<USERNAME>')
+user_to_disable = User.find_by_username('<USERNAME>')
+
+TwoFactor::DestroyService.new(admin, user: user_to_disable).execute
+```
+
+### For all users
+
 There may be some special situations where you want to disable 2FA for everyone
 even when forced 2FA is disabled. There is a Rake task for that:
 
@@ -100,10 +124,6 @@ sudo gitlab-rake gitlab:two_factor:disable_for_all_users
 sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production
 ```
 
-WARNING:
-This is a permanent and irreversible action. Users have to
-reactivate 2FA from scratch if they want to use it again.
-
 ## 2FA for Git over SSH operations **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7.