From 4555e1b21c365ed8303ffb7a3325d773c9b8bf31 Mon Sep 17 00:00:00 2001
From: GitLab Bot <gitlab-bot@gitlab.com>
Date: Wed, 19 May 2021 15:44:42 +0000
Subject: Add latest changes from gitlab-org/gitlab@13-12-stable-ee

---
 doc/security/rate_limits.md               |  1 +
 doc/security/reset_user_password.md       |  8 ++++----
 doc/security/ssh_keys_restrictions.md     |  6 +++---
 doc/security/token_overview.md            | 12 ++++++++++++
 doc/security/two_factor_authentication.md | 18 +++++++++---------
 5 files changed, 29 insertions(+), 16 deletions(-)

(limited to 'doc/security')

diff --git a/doc/security/rate_limits.md b/doc/security/rate_limits.md
index 1609607ea5c..157600c15fb 100644
--- a/doc/security/rate_limits.md
+++ b/doc/security/rate_limits.md
@@ -33,6 +33,7 @@ These are rate limits you can set in the Admin Area of your instance:
 - [Protected paths](../user/admin_area/settings/protected_paths.md)
 - [Raw endpoints rate limits](../user/admin_area/settings/rate_limits_on_raw_endpoints.md)
 - [User and IP rate limits](../user/admin_area/settings/user_and_ip_rate_limits.md)
+- [Package registry rate limits](../user/admin_area/settings/package_registry_rate_limits.md)
 
 ## Non-configurable limits
 
diff --git a/doc/security/reset_user_password.md b/doc/security/reset_user_password.md
index 5f46ebcec31..344cfcae46a 100644
--- a/doc/security/reset_user_password.md
+++ b/doc/security/reset_user_password.md
@@ -20,8 +20,8 @@ which can be invoked by the following command:
 sudo gitlab-rake "gitlab:password:reset"
 ```
 
-You will be asked for username, password, and password confirmation. Upon giving
-proper values for them, the password of the specified user will be updated.
+GitLab asks for a username, a password, and a password confirmation. Upon giving
+proper values for them, the password of the specified user is updated.
 
 The Rake task also takes the username as an argument, as shown in the example
 below:
@@ -91,7 +91,7 @@ Try fixing this on the rails console. For example, if your new `root` password i
 
 1. [Start a Rails console](../administration/operations/rails_console.md).
 
-1. Find the user and skip reconfirmation. Any of the methods to find the user, above, will work:
+1. Find the user and skip reconfirmation, using any of the methods above:
 
     ```ruby
     user = User.find(1)
@@ -110,7 +110,7 @@ password.
 
 If the username was changed to something else and has been forgotten, one
 possible way is to reset the password using Rails console with user ID `1` (in
-almost all the cases, the first user will be the default admin account).
+almost all the cases, the first user is the default admin account).
 
 <!-- ## Troubleshooting
 
diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md
index 102ba1fc370..0875ce82e61 100644
--- a/doc/security/ssh_keys_restrictions.md
+++ b/doc/security/ssh_keys_restrictions.md
@@ -25,13 +25,13 @@ In **Admin Area > Settings** (`/admin/application_settings/general`), expand the
 
 ![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
 
-If a restriction is imposed on any key type, users will be unable to upload new SSH keys that don't meet the requirement. Any existing keys that don't meet it will be disabled but not removed and users will be unable to pull or push code using them.
+If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the requirement. Any existing keys that don't meet it are disabled but not removed and users cannot to pull or push code using them.
 
-An icon will be visible to the user of a restricted key in the SSH keys section of their profile:
+An icon is visible to the user of a restricted key in the SSH keys section of their profile:
 
 ![Restricted SSH key icon](img/ssh_keys_restricted_key_icon.png)
 
-Hovering over this icon will tell you why the key is restricted.
+Hovering over this icon tells you why the key is restricted.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md
index 0ca1e07bf54..f9655210329 100644
--- a/doc/security/token_overview.md
+++ b/doc/security/token_overview.md
@@ -106,3 +106,15 @@ This table shows available scopes per token. Scopes can be limited further on to
 1. Limited to the one project.
 1. Runner registration and authentication token don't provide direct access to repositories, but can be used to register and authenticate a new runner that may execute jobs which do have access to the repository
 1. Limited to certain [endpoints](../api/README.md#gitlab-cicd-job-token).
+
+## Security considerations
+
+Access tokens should be treated like passwords and kept secure.
+
+Adding them to URLs is a security risk. This is especially true when cloning or adding a remote, as Git then writes the URL to its `.git/config` file in plain text. URLs are also generally logged by proxies and application servers, which makes those credentials visible to system administrators.
+
+Instead, API calls can be passed an access token using headers, like [the `Private-Token` header](../api/README.md#personalproject-access-tokens).
+
+Tokens can also be stored using a [Git credential storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
+
+When creating a scoped token, consider using the most limited scope possible to reduce the impact of accidentally leaking the token.
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index 1abd4502eb5..f2728f95b96 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -23,8 +23,8 @@ want to enforce everyone to set up 2FA, you can choose from two different ways:
 - Enforce on next login.
 - Suggest on next login, but allow a grace period before enforcing.
 
-After the configured grace period has elapsed, users will be able to sign in but
-won't be able to leave the 2FA configuration area at `/profile/two_factor_auth`.
+After the configured grace period has elapsed, users can sign in but
+cannot leave the 2FA configuration area at `/profile/two_factor_auth`.
 
 To enable 2FA for all users:
 
@@ -37,6 +37,8 @@ change the grace period to `0`.
 
 ## Enforcing 2FA for all users in a group
 
+> [Introduced in](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups.
+
 If you want to enforce 2FA only for certain groups, you can:
 
 1. Enable it in the group's **Settings > General** page. Navigate to
@@ -47,8 +49,6 @@ If you want to enforce 2FA only for certain groups, you can:
 
 To change this setting, you need to be administrator or owner of the group.
 
-> [From](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups.
-
 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
 need to be administrator or owner of the group.
@@ -66,21 +66,21 @@ The following are important notes about 2FA:
 - If you add additional members to a project within a group or subgroup that has
   2FA enabled, 2FA is **not** required for those individually added members.
 - If there are multiple 2FA requirements (for example, group + all users, or multiple
-  groups) the shortest grace period will be used.
+  groups) the shortest grace period is used.
 - It is possible to disallow subgroups from setting up their own 2FA requirements.
-  Navigate to the top-level group's **Settings > General > Permissions, LFS, 2FA > Two-factor authentication** and uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. This action will cause all subgroups with 2FA requirements to stop requiring that from their members.
+  Navigate to the top-level group's **Settings > General > Permissions, LFS, 2FA > Two-factor authentication** and 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.
 
 ## Disabling 2FA for everyone
 
 WARNING:
 Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforcing-2fa-for-all-users)
 or [enforce 2FA for all users in a group](#enforcing-2fa-for-all-users-in-a-group)
-settings. In addition to the steps in this section, you will need to disable any enforced 2FA
+settings. In addition to the steps in this section, you must disable any enforced 2FA
 settings so users aren't asked to set up 2FA again, the next time the user signs in to GitLab.
 Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforcing-2fa-for-all-users)
 or [enforce 2FA for all users in a group](#enforcing-2fa-for-all-users-in-a-group)
 settings if they have been configured. In addition to the steps in this section,
-you will need to disable any enforced 2FA settings so users aren't asked to setup
+you must disable any enforced 2FA settings so users aren't asked to setup
 2FA again when the next login to GitLab.
 
 There may be some special situations where you want to disable 2FA for everyone
@@ -95,7 +95,7 @@ sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_EN
 ```
 
 WARNING:
-This is a permanent and irreversible action. Users will have to
+This is a permanent and irreversible action. Users have to
 reactivate 2FA from scratch if they want to use it again.
 
 <!-- ## Troubleshooting
-- 
cgit v1.2.3