Add latest changes from gitlab-org/gitlab@master

14 files changed, 118 insertions, 28 deletions

diff --git a/doc/administration/auth/cognito.md b/doc/administration/auth/cognito.md
index bb06d5d1a58..d12797b5359 100644
--- a/doc/administration/auth/cognito.md
+++ b/doc/administration/auth/cognito.md
@@ -33,7 +33,7 @@ To enable AWS Cognito as an authentication provider, complete the following step
    - **Enabled Identity Providers** - select all
    - **Callback URL** - `https://<your_gitlab_instance_url>/users/auth/cognito/callback`
    - **Allowed OAuth Flows** - Authorization code grant
-   - **Allowed OAuth2 Scopes** - `email`, `openid`, and `profile`
+   - **Allowed OAuth 2.0 Scopes** - `email`, `openid`, and `profile`
 
 1. Save changes for the app client settings.
 1. Under **Domain name**, include the AWS domain name for your AWS Cognito application.
diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md
index cec18960dfd..1516b82a906 100644
--- a/doc/administration/gitaly/reference.md
+++ b/doc/administration/gitaly/reference.md
@@ -26,7 +26,7 @@ At the top level, `config.toml` defines the items described on the table below.
 | `socket_path` | string | yes (if  `listen_addr` is not set) | A path which Gitaly should open a Unix socket. |
 | `listen_addr` | string | yes (if `socket_path` is not set) | TCP address for Gitaly to listen on. |
 | `tls_listen_addr` | string | no | TCP over TLS address for Gitaly to listen on. |
-| `bin_dir`    | string | yes    | Directory containing Gitaly's executables. |
+| `bin_dir`    | string | yes    | Directory containing Gitaly executables. |
 | `prometheus_listen_addr` | string | no | TCP listen address for Prometheus metrics. If not set, no Prometheus listener is started. |
 
 For example:
@@ -100,7 +100,7 @@ by GitLab with names, such as `default`.
 
 These names and paths are also defined in the `gitlab.yml` configuration file of
 GitLab. When you run Gitaly on the same machine as GitLab (the default
-and recommended configuration) storage paths defined in Gitaly's `config.toml`
+and recommended configuration) storage paths defined in the Gitaly `config.toml`
 must match those in `gitlab.yml`.
 
 | Name | Type | Required | Description |
@@ -146,7 +146,7 @@ The default limit is 100 `cat-file`s, which constitute a pair of
 you are seeing errors complaining about "too many open files", or an
 inability to create new processes, you may want to lower this limit.
 
-Ideally, the number should be large enough to handle normal
+Ideally, the number should be large enough to handle standard
 traffic. If you raise the limit, you should measure the cache hit ratio
 before and after. If the hit ratio does not improve, the higher limit is
 probably not making a meaningful difference. Here is an example
diff --git a/doc/administration/monitoring/prometheus/web_exporter.md b/doc/administration/monitoring/prometheus/web_exporter.md
index 5539526c501..0212091f14c 100644
--- a/doc/administration/monitoring/prometheus/web_exporter.md
+++ b/doc/administration/monitoring/prometheus/web_exporter.md
@@ -22,7 +22,7 @@ We provide two mechanisms by which web application metrics can be exported:
   makes metric data available via its own `/-/metrics` endpoint. This is the default,
   and is described in [GitLab Metrics](index.md#gitlab-metrics). We recommend this
   default for small GitLab installations where the amount of metrics collected is small.
-- Through a dedicated metrics server. Enabling this server will cause Puma to launch an
+- Through a dedicated metrics server. Enabling this server causes Puma to launch an
   additional process whose sole responsibility is to serve metrics. This approach leads
   to better fault isolation and performance for very large GitLab installations, but
   comes with additional memory use. We recommend this approach for medium to large
@@ -69,5 +69,5 @@ To serve metrics via HTTPS instead of HTTP, enable TLS in the exporter settings:
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
 
-When TLS is enabled, the same `port` and `address` will be used as described above.
+When TLS is enabled, the same `port` and `address` is used as described above.
 The metrics server cannot serve both HTTP and HTTPS at the same time.
diff --git a/doc/api/groups.md b/doc/api/groups.md
index dd3f8baf338..c39b8584e93 100644
--- a/doc/api/groups.md
+++ b/doc/api/groups.md
@@ -1201,7 +1201,8 @@ GET /groups?search=foobar
 
 > Introduced in GitLab 14.8.
 
-Get a list of users provisioned by a given group. Does not include users provisioned by subgroups.
+Get a list of users provisioned by a given group. Does not include subgroups.
+Users in this list are considered [enterprise users](../user/enterprise_user/index.md).
 
 Requires at least the Maintainer role on the group.
 
diff --git a/doc/api/members.md b/doc/api/members.md
index 2da84866b92..4032ab1d651 100644
--- a/doc/api/members.md
+++ b/doc/api/members.md
@@ -29,8 +29,7 @@ In GitLab 14.8 and earlier, projects in personal namespaces have an `access_leve
 
 The `group_saml_identity` attribute is only visible to a group owner for [SSO enabled groups](../user/group/saml_sso/index.md).
 
-The `email` attribute is only visible to group owners when the user was provisioned by the group.
-Users are provisioned by the group when the account was created via [SCIM](../user/group/saml_sso/scim_setup.md) or by first sign-in with [SAML SSO for GitLab.com groups](../user/group/saml_sso/index.md).
+The `email` attribute is only visible to group Owners for any [enterprise user](../user/enterprise_user/index.md).
 
 ## List all members of a group or project
 
diff --git a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
index 261390d1d14..e7e031fb82a 100644
--- a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
+++ b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
@@ -796,18 +796,16 @@ strategy here to share knowledge and solicit feedback from other team members.
 
 ## Who
 
-Authors:
+DRIs:
 
 <!-- vale gitlab.Spelling = NO -->
 
-| Role   | Who            |
-|--------|----------------|
-| Author | Grzegorz Bizon |
-
-Recommenders:
-
-| Role                          | Who             |
-|-------------------------------|-----------------|
-| Senior Distingiushed Engineer | Kamil Trzciński |
+| Role                | Who                                            |
+|---------------------|------------------------------------------------|
+| Author              | Grzegorz Bizon, Principal Engineer             |
+| Recommender         | Kamil Trzciński, Senior Distingiushed Engineer |
+| Product Manager     | James Heimbuck, Senior Product Manager         |
+| Engineering Manager | Scott Hampton, Engineering Manager             |
+| Lead Engineer       | Marius Bobin, Senior Backend Engineer          |
 
 <!-- vale gitlab.Spelling = YES -->
diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md
index 0f206b3fceb..07ba3d8f916 100644
--- a/doc/ci/git_submodules.md
+++ b/doc/ci/git_submodules.md
@@ -67,7 +67,7 @@ To make submodules work correctly in CI/CD jobs:
      GIT_SUBMODULE_DEPTH: 1
    ```
 
-1. You can filter or exclude specific submodules to control which submodules will be synced using
+1. You can filter or exclude specific submodules to control which submodules are synchronized using
    [`GIT_SUBMODULE_PATHS`](runners/configure_runners.md#sync-or-exclude-specific-submodules-from-ci-jobs).
 
    ```yaml
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index 63e9993be90..71deaadf9ec 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -99,7 +99,7 @@ Some high level differences between the products worth mentioning are:
   feature.
 - The [`parallel`](../yaml/index.md#parallel) keyword can automatically parallelize tasks,
   like tests that support parallelization.
-- Normally all jobs in a single stage run in parallel, and all stages run in sequence.
+- Usually all jobs in a single stage run in parallel, and all stages run in sequence.
   Different [pipeline architectures](../pipelines/pipeline_architectures.md) allow you to change this behavior.
 - The new [`rules` syntax](../yaml/index.md#rules) is the recommended method of
   controlling when different jobs run. It is more powerful than the `only/except` syntax.
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 6783ab1bfed..17ce184ee28 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -324,6 +324,13 @@ On a self-managed instance, you can [increase the size limits](../administration
 A [loop of included configuration files](pipeline_editor/index.md#configuration-validation-currently-not-available-message)
 can cause a `500` error when editing the `.gitlab-ci.yml` file with the [web editor](../user/project/repository/web_editor.md).
 
+### A CI/CD job does not use newer configuration when run again
+
+The configuration for a pipeline is only fetched when the pipeline is created.
+When you rerun a job, uses the same configuration each time. If you update configuration files,
+including separate files added with [`include`](yaml/index.md#include), you must
+start a new pipeline to use the new configuration.
+
 ## Pipeline warnings
 
 Pipeline configuration warnings are shown when you:
diff --git a/doc/user/enterprise_user/index.md b/doc/user/enterprise_user/index.md
new file mode 100644
index 00000000000..d8305f0288b
--- /dev/null
+++ b/doc/user/enterprise_user/index.md
@@ -0,0 +1,71 @@
+---
+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
+type: reference
+---
+
+# Enterprise users **(PREMIUM SAAS)**
+
+Enterprise users have user accounts that are administered by an organization that
+has purchased a [GitLab subscription](../../subscriptions/index.md).
+
+Enterprise users are identified by the [**Enterprise** badge](../project/badges.md)
+next to their names on the [Members list](../group/manage.md#filter-and-sort-members-in-a-group).
+
+## Provision an enterprise user
+
+A user account is considered an enterprise account when:
+
+- A user without an existing GitLab user account uses the group's
+  [SAML SSO](../group/saml_sso/index.md) to sign in for the first time.
+- [SCIM](../group/saml_sso/scim_setup.md) creates the user account on behalf of
+  the group.
+
+A user can also [manually connect an identity provider (IdP) to a GitLab account whose email address matches the subscribing organization's domain](../group/saml_sso/index.md#linking-saml-to-your-existing-gitlabcom-account).
+By selecting **Authorize** when connecting these two accounts, the user account
+with the matching email address is classified as an enterprise user. However, this
+user account does not have an **Enterprise** badge in GitLab.
+
+Although a user can be a member of more than one group, each user account can be
+provisioned by only one group. As a result, a user is considered an enterprise
+user under one top-level group only.
+
+## Manage enterprise users in a namespace
+
+A top-level Owner of a namespace on a paid plan can retrieve information about and
+manage enterprise user accounts in that namespace.
+
+These enterprise user-specific actions are in addition to the standard
+[group member permissions](../permissions.md#group-members-permissions).
+
+### Disable two-factor authentication
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9484) in GitLab 15.8.
+
+Top-level group Owners can disable two-factor authentication (2FA) for enterprise users.
+
+To disable 2FA:
+
+1. On the top bar, select **Main menu > Groups** and find your group.
+1. On the left sidebar, select **Group information > Members**.
+1. Find a user with the **Enterprise** and **2FA** badges.
+1. Select **More actions** (**{ellipsis_v}**) and select **Disable two-factor authentication**.
+
+### Prevent users from creating groups and projects outside the corporate group
+
+A SAML IdP administrator or a top-level group Owner can use a SAML response to set:
+
+- Whether users can create groups.
+- The maximum number of personal projects users can create.
+
+For more information, see the [supported user attributes for SAML responses](../group/saml_sso/index.md#supported-user-attributes).
+
+### Bypass email confirmation for provisioned users
+
+A top-level group Owner can [set up verified domains to bypass confirmation emails](../group/saml_sso/index.md#bypass-user-email-confirmation-with-verified-domains).
+
+### Get users' email addresses through the API
+
+A top-level group Owner can use the [group and project members API](../../api/members.md)
+to access users' information, including email addresses.
diff --git a/doc/user/group/manage.md b/doc/user/group/manage.md
index a755447c47c..aec2932a9e4 100644
--- a/doc/user/group/manage.md
+++ b/doc/user/group/manage.md
@@ -131,7 +131,7 @@ Filter a group to find members. By default, all members in the group and subgrou
 In lists of group members, entries can display the following badges:
 
 - **SAML**, to indicate the member has a [SAML account](saml_sso/index.md) connected to them.
-- **Enterprise**, to indicate that [SCIM created the account](saml_sso/scim_setup.md).
+- **Enterprise**, to indicate that the member is an [enterprise user](../enterprise_user/index.md).
 
 1. On the top bar, select **Main menu > Groups** and find your group.
 1. Above the list of members, in the **Filter members** box, enter filter criteria.
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index fcb02e76095..35695c14f1a 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -333,7 +333,7 @@ To migrate users to a new email domain, users must:
 ## User access and management
 
 > - SAML user provisioning [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/268142) in GitLab 13.7.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325712) in GitLab 14.0, GitLab users created by [SAML SSO](index.md#user-access-and-management) or SCIM provisioning are displayed with an **Enterprise** badge in the **Members** view.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325712) in GitLab 14.0, GitLab users created by [SAML SSO](index.md#user-access-and-management) or SCIM provisioning are displayed with an ][**Enterprise**](../../enterprise_user/index.md) badge in the **Members** view.
 
 After group SSO is configured and enabled, users can access the GitLab.com group through the identity provider's dashboard.
 If [SCIM](scim_setup.md) is configured, see [user access](scim_setup.md#user-access) on the SCIM page.
@@ -431,7 +431,7 @@ convert the information to XML. An example SAML response is shown here.
 
 By default, users provisioned with SAML or SCIM are sent a verification email to verify their identity. Instead, you can
 [configure GitLab with a custom domain](../../project/pages/custom_domains_ssl_tls_certification/index.md) and GitLab
-automatically confirms user accounts. Users still receive an enterprise user welcome email. Confirmation is bypassed for
+automatically confirms user accounts. Users still receive an [enterprise user](../../enterprise_user/index.md) welcome email. Confirmation is bypassed for
 users:
 
 - That are provisioned with SAML or SCIM.
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index 8c30c246566..79fc1ab310a 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -170,7 +170,7 @@ encounter issues.
 
 ## User access
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325712) in GitLab 14.0, GitLab users created by [SAML SSO](index.md#user-access-and-management) or SCIM provisioning are displayed with an **Enterprise** badge in the **Members** view.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325712) in GitLab 14.0, GitLab users created by [SAML SSO](index.md#user-access-and-management) or SCIM provisioning are displayed with an [**Enterprise**](../../enterprise_user/index.md) badge in the **Members** view.
 
 During the synchronization process, all new users:
 
diff --git a/doc/user/group/saml_sso/troubleshooting.md b/doc/user/group/saml_sso/troubleshooting.md
index f24fa4c5bac..0151ae52bb6 100644
--- a/doc/user/group/saml_sso/troubleshooting.md
+++ b/doc/user/group/saml_sso/troubleshooting.md
@@ -58,6 +58,16 @@ You can use one of the following to troubleshoot SAML:
 
 For convenience, we've included some [example resources](../../../user/group/saml_sso/example_saml_config.md) used by our Support Team. While they may help you verify the SAML app configuration, they are not guaranteed to reflect the current state of third-party products.
 
+### Calculate the fingerprint
+
+If you use a `idp_cert_fingerprint`, it must be a SHA1 fingerprint. To calculate a SHA1 fingerprint, download the certificate file and run:
+
+```shell
+openssl x509 -in <filename.crt> -noout -fingerprint -sha1
+```
+
+Replace `filename.crt` with the name of the certificate file.
+
 ## Searching Rails log for a SAML response **(FREE SELF)**
 
 You can find the base64-encoded SAML Response in the [`production_json.log`](../../../administration/logs/index.md#production_jsonlog).
@@ -122,13 +132,17 @@ must be validated using either a fingerprint, a certificate, or a validator.
 
 For this requirement, be sure to take the following into account:
 
-- If a fingerprint is used, it must be the SHA1 fingerprint
+- If you use a fingerprint, it must be the correct SHA1 fingerprint. To confirm that you are using
+  the correct SHA1 fingerprint:
+  1. Re-download the certificate file.
+  1. [Calculate the fingerprint](#calculate-the-fingerprint).
+  1. Compare the fingerprint to the value provided in `idp_cert_fingerprint`. The values should be the same.
 - If no certificate is provided in the settings, a fingerprint or fingerprint
   validator needs to be provided and the response from the server must contain
-  a certificate (`<ds:KeyInfo><ds:X509Data><ds:X509Certificate>`)
+  a certificate (`<ds:KeyInfo><ds:X509Data><ds:X509Certificate>`).
 - If a certificate is provided in the settings, it is no longer necessary for
   the request to contain one. In this case the fingerprint or fingerprint
-  validators are optional
+  validators are optional.
 
 If none of the above described scenarios is valid, the request
 fails with one of the mentioned errors.