Add latest changes from gitlab-org/gitlab@master

7 files changed, 64 insertions, 43 deletions

diff --git a/doc/user/admin_area/credentials_inventory.md b/doc/user/admin_area/credentials_inventory.md
index 21ac0f720ec..bcf15192ef0 100644
--- a/doc/user/admin_area/credentials_inventory.md
+++ b/doc/user/admin_area/credentials_inventory.md
@@ -40,7 +40,7 @@ To access the Credentials inventory:
 
 If you see a **Revoke** button, you can revoke that user's PAT. Whether you see a **Revoke** button depends on the token state, and if an expiration date has been set. For more information, see the following table:
 
-| Token state | [Token expiration enforced?](settings/account_and_limit_settings.md#allow-expired-personal-access-tokens-to-be-used-deprecated) | Show Revoke button? | Comments |
+| Token state | [Token expiration enforced?](settings/account_and_limit_settings.md#allow-expired-access-tokens-to-be-used-deprecated) | Show Revoke button? | Comments |
 |-------------|------------------------|--------------------|----------------------------------------------------------------------------|
 | Active      | Yes                    | Yes                | Allows administrators to revoke the PAT, such as for a compromised account |
 | Active      | No                     | Yes                | Allows administrators to revoke the PAT, such as for a compromised account |
diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md
index e6d8107ed9b..4ad26de31d3 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -249,15 +249,16 @@ To allow the use of expired SSH keys:
 
 Disabling SSH key expiration immediately enables all expired SSH keys.
 
-## Limit the lifetime of personal access tokens **(ULTIMATE SELF)**
+## Limit the lifetime of access tokens **(ULTIMATE SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab 12.6.
 
 Users can optionally specify a lifetime for
-[personal access tokens](../../profile/personal_access_tokens.md).
+access tokens, this includes [personal](../../profile/personal_access_tokens.md), 
+[group](../../group/settings/group_access_tokens.md), and [project](../../project/settings/project_access_tokens.md) access tokens.
 This lifetime is not a requirement, and can be set to any arbitrary number of days.
 
-Personal access tokens are the only tokens needed for programmatic access to GitLab.
+Access tokens are the only tokens needed for programmatic access to GitLab.
 However, organizations with security requirements may want to enforce more protection by
 requiring the regular rotation of these tokens.
 
@@ -266,15 +267,15 @@ requiring the regular rotation of these tokens.
 Only a GitLab administrator can set a lifetime. Leaving it empty means
 there are no restrictions.
 
-To set a lifetime on how long personal access tokens are valid:
+To set a lifetime on how long access tokens are valid:
 
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Account and limit** section.
-1. Fill in the **Maximum allowable lifetime for personal access tokens (days)** field.
+1. Fill in the **Maximum allowable lifetime for access tokens (days)** field.
 1. Click **Save changes**.
 
-Once a lifetime for personal access tokens is set, GitLab:
+Once a lifetime for access tokens is set, GitLab:
 
 - Applies the lifetime for new personal access tokens, and require users to set an expiration date
   and a date no later than the allowed lifetime.
@@ -282,7 +283,7 @@ Once a lifetime for personal access tokens is set, GitLab:
   allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime,
   or remove it, before revocation takes place.
 
-## Allow expired Personal Access Tokens to be used (DEPRECATED) **(ULTIMATE SELF)**
+## Allow expired access tokens to be used (DEPRECATED) **(ULTIMATE SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in GitLab 13.1.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/296881) in GitLab 13.9.
@@ -298,7 +299,7 @@ To allow the use of expired PATs:
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Account and limit** section.
-1. Uncheck the **Enforce personal access token expiration** checkbox.
+1. Uncheck the **Enforce access token expiration** checkbox.
 
 ## Disable user profile name changes **(PREMIUM SELF)**
 
diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md
index bffaef40800..6771ff8739a 100644
--- a/doc/user/group/saml_sso/group_managed_accounts.md
+++ b/doc/user/group/saml_sso/group_managed_accounts.md
@@ -107,14 +107,14 @@ Since personal access tokens are the only token needed for programmatic access t
 ### Set a limit
 
 Only a GitLab administrator or an owner of a group-managed account can set a limit. When this field
-is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens)
+is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens)
 on the lifetime of personal access tokens apply.
 
 To set a limit on how long personal access tokens are valid for users in a group managed account:
 
 1. Navigate to the **Settings > General** page in your group's sidebar.
 1. Expand the **Permissions and group features** section.
-1. Fill in the **Maximum allowable lifetime for personal access tokens (days)** field.
+1. Fill in the **Maximum allowable lifetime for access tokens (days)** field.
 1. Click **Save changes**.
 
 Once a lifetime for personal access tokens is set:
diff --git a/doc/user/group/settings/group_access_tokens.md b/doc/user/group/settings/group_access_tokens.md
index 0666303bcf8..4b791d5a221 100644
--- a/doc/user/group/settings/group_access_tokens.md
+++ b/doc/user/group/settings/group_access_tokens.md
@@ -25,7 +25,7 @@ Group access tokens are similar to [project access tokens](../../project/setting
 and [personal access tokens](../../profile/personal_access_tokens.md), except they are
 associated with a group rather than a project or user.
 
-In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) as personal access tokens if the limit is set.
+In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) as personal access tokens if the limit is set.
 
 You can use group access tokens:
 
@@ -50,7 +50,7 @@ To create a group access token:
 1. On the top bar, select **Menu > Groups** and find your group.
 1. On the left sidebar, select **Settings > Access Tokens**.
 1. Enter a name. The token name is visible to any user with permissions to view the group.
-1. Optional. Enter an expiry date for the token. The token will expire on that date at midnight UTC. An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
+1. Optional. Enter an expiry date for the token. The token will expire on that date at midnight UTC. An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
 1. Select a role for the token.
 1. Select the [desired scopes](#scopes-for-a-group-access-token).
 1. Select  **Create group access token**.
diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md
index 4c132094d24..8b6c05796a5 100644
--- a/doc/user/profile/personal_access_tokens.md
+++ b/doc/user/profile/personal_access_tokens.md
@@ -109,9 +109,9 @@ Personal access tokens expire on the date you define, at midnight UTC.
 - GitLab runs a check at 01:00 AM UTC every day to identify personal access tokens that expire in the next seven days. The owners of these tokens are notified by email.
 - GitLab runs a check at 02:00 AM UTC every day to identify personal access tokens that expire on the current date. The owners of these tokens are notified by email.
 - In GitLab Ultimate, administrators can
-  [limit the lifetime of personal access tokens](../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens).
+  [limit the lifetime of access tokens](../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens).
 - In GitLab Ultimate, administrators can choose whether or not to
-  [enforce personal access token expiration](../admin_area/settings/account_and_limit_settings.md#allow-expired-personal-access-tokens-to-be-used-deprecated).
+  [enforce access token expiration](../admin_area/settings/account_and_limit_settings.md#allow-expired-access-tokens-to-be-used-deprecated).
 
 ## Create a personal access token programmatically **(FREE SELF)**
 
diff --git a/doc/user/project/repository/push_rules.md b/doc/user/project/repository/push_rules.md
index bb473a2830b..6918490c404 100644
--- a/doc/user/project/repository/push_rules.md
+++ b/doc/user/project/repository/push_rules.md
@@ -20,6 +20,52 @@ can enable in a user-friendly interface. They are defined either:
 - Per project, so you can have different rules applied to different
   projects depending on your needs.
 
+## Default push rules
+
+The following options are available:
+
+- **Reject unverified users** - GitLab rejects any commit that was not committed
+  by the same user as the user who pushed it, or where the committer's email address
+  is not [confirmed](../../../security/user_email_confirmation.md).
+- **Reject unsigned commits** - Reject commit when it is not signed through GPG.
+  Read [signing commits with GPG](gpg_signed_commits/index.md).
+- **Removal of tags with** `git push` - Forbid users to remove Git tags with `git push`.
+  Tags can be deleted through the web UI.
+- **Check whether the commit author is a GitLab user** - Restrict commits to existing
+  GitLab users (checked against their email addresses). Checks both the commit author and committer.
+- **Prevent pushing secret files** - GitLab rejects any files that are
+  [likely to contain secrets](#prevent-pushing-secrets-to-the-repository).
+
+These push rules require you to create a regular expression for the rule to evaluate:
+
+- **Require expression in commit messages** - Only commit messages that match this
+  regular expression can be pushed. To allow any commit message, leave empty.
+  Uses multiline mode, which can be disabled using `(?-m)`.
+- **Reject expression in commit messages** - Only commit messages that do not match
+  this regular expression can be pushed. To allow any commit message, leave empty.
+  Uses multiline mode, which can be disabled using `(?-m)`.
+- **Restrict by branch name** - Only branch names that match this regular expression
+  can be pushed. To allow any branch name, leave empty.
+- **Restrict by commit author's email** - Only the commit author's email address that matches this
+  regular expression can be pushed. Checks both the commit author and committer.
+  To allow any email address, leave empty.
+- **Prohibited file names** - Any committed file names that match this regular expression
+  and do not already exist in the repository can't be pushed. To allow all file names,
+  leave empty. See [common examples](#prohibited-file-names).
+- **Maximum file size** - Pushes that contain added or updated files that exceed this
+  file size (in MB) are rejected. To allow files of any size, set to `0`.
+  Files tracked by Git LFS are exempted.
+
+GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions
+in push rules, and you can test them at the [regex101 regex tester](https://regex101.com/).
+
+## Custom push rules **(PREMIUM SELF)**
+
+It's possible to create custom push rules rather than the push rules available in
+**Admin Area > Push Rules** by using more advanced server hooks.
+
+See [server hooks](../../../administration/server_hooks.md) for more information.
+
 ## Use cases
 
 Every push rule could have its own use case, but let's consider some examples.
@@ -72,13 +118,6 @@ Some example regular expressions you can use in push rules:
 By default, GitLab restricts certain formats of branch names for security purposes.
 40-character hexadecimal names, similar to Git commit hashes, are prohibited.
 
-### Custom Push Rules **(PREMIUM SELF)**
-
-It's possible to create custom push rules rather than the push rules available in
-**Admin Area > Push Rules** by using more advanced server hooks.
-
-See [server hooks](../../../administration/server_hooks.md) for more information.
-
 ## Enabling push rules
 
 You can create push rules for all new projects to inherit, but they can be overridden
@@ -97,25 +136,6 @@ To override global push rules in a project's settings:
 1. Set the rule you want.
 1. Select **Save push rules**.
 
-The following options are available:
-
-| Push rule                       | Description |
-|---------------------------------|-------------|
-| Removal of tags with `git push` | Forbid users to remove Git tags with `git push`. Tags can be deleted through the web UI. |
-| Check whether the commit author is a GitLab user | Restrict commits to existing GitLab users (checked against their emails). <sup>1</sup> |
-| Reject unverified users | GitLab rejects any commit that was not committed by the same user as the user who pushed it, or where the committer's email address is not [confirmed](../../../security/user_email_confirmation.md). |
-| Check whether commit is signed through GPG | Reject commit when it is not signed through GPG. Read [signing commits with GPG](gpg_signed_commits/index.md). |
-| Prevent pushing secret files | GitLab rejects any files that are likely to contain secrets. See the [forbidden file names](#prevent-pushing-secrets-to-the-repository). |
-| Require expression in commit messages | Only commit messages that match this regular expression are allowed to be pushed. <sup>2</sup> Leave empty to allow any commit message. Uses multiline mode, which can be disabled using `(?-m)`. |
-| Reject expression in commit messages | Only commit messages that do not match this regular expression are allowed to be pushed. <sup>2</sup> Leave empty to allow any commit message. Uses multiline mode, which can be disabled using `(?-m)`. |
-| Restrict by branch name | Only branch names that match this regular expression are allowed to be pushed. <sup>2</sup> Leave empty to allow all branch names. |
-| Restrict by commit author's email | Only commit author's email that match this regular expression are allowed to be pushed. <sup>1</sup> <sup>2</sup> Leave empty to allow any email. |
-| Prohibited file names | Any committed filenames that match this regular expression and do not already exist in the repository are not allowed to be pushed. <sup>2</sup> Leave empty to allow any filenames. See [common examples](#prohibited-file-names). |
-| Maximum file size | Pushes that contain added or updated files that exceed this file size (in MB) are rejected. Set to 0 to allow files of any size. Files tracked by Git LFS are exempted. |
-
-1. Checks both the commit author and committer.
-1. GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions in push rules, and you can test them at the [regex101 regex tester](https://regex101.com/).
-
 ### Caveat to "Reject unsigned commits" push rule
 
 This push rule ignores commits that are authenticated and created by GitLab
diff --git a/doc/user/project/settings/project_access_tokens.md b/doc/user/project/settings/project_access_tokens.md
index b66913b7223..e332b74f908 100644
--- a/doc/user/project/settings/project_access_tokens.md
+++ b/doc/user/project/settings/project_access_tokens.md
@@ -25,7 +25,7 @@ Use a project access token to authenticate:
 Project access tokens are similar to [group access tokens](../../group/settings/group_access_tokens.md)
 and [personal access tokens](../../profile/personal_access_tokens.md).
 
-In self-managed instances, project access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) as personal access tokens if the limit is set.
+In self-managed instances, project access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) as personal access tokens if the limit is set.
 
 You can use project access tokens:
 
@@ -48,7 +48,7 @@ To create a project access token:
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > Access Tokens**.
 1. Enter a name. The token name is visible to any user with permissions to view the project.
-1. Optional. Enter an expiry date for the token. The token expires on that date at midnight UTC. An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
+1. Optional. Enter an expiry date for the token. The token expires on that date at midnight UTC. An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
 
 1. Select a role for the token.
 1. Select the [desired scopes](#scopes-for-a-project-access-token).