Add latest changes from gitlab-org/gitlab@13-1-stable-ee

14 files changed, 47 insertions, 150 deletions

diff --git a/doc/integration/akismet.md b/doc/integration/akismet.md
index 5b697d387e9..7cb8f8b70ce 100644
--- a/doc/integration/akismet.md
+++ b/doc/integration/akismet.md
@@ -1,42 +1,36 @@
 # Akismet
 
-> *Note:* Before 8.11 only issues submitted via the API and for non-project
-members were submitted to Akismet.
-
 GitLab leverages [Akismet](https://akismet.com/) to protect against spam. Currently
 GitLab uses Akismet to prevent the creation of spam issues on public projects. Issues
-created via the WebUI or the API can be submitted to Akismet for review.
+created via the web UI or the API can be submitted to Akismet for review.
 
 Detected spam will be rejected, and an entry in the "Spam Log" section in the
 Admin page will be created.
 
-Privacy note: GitLab submits the user's IP and user agent to Akismet. Note that
-adding a user to a project will disable the Akismet check and prevent this
-from happening.
+Privacy note: GitLab submits the user's IP and user agent to Akismet.
+
+NOTE: **Note:**
+In GitLab 8.11 and later, all issues are submitted to Akismet.
+In earlier GitLab versions, this only applied to API and non-project members.
 
 ## Configuration
 
 To use Akismet:
 
 1. Go to the URL: <https://akismet.com/account/>
-
 1. Sign-in or create a new account.
-
 1. Click on **Show** to reveal the API key.
-
 1. Go to **Admin Area > Settings > Reporting** (`/admin/application_settings/reporting`).
-
 1. Check the **Enable Akismet** checkbox.
-
 1. Fill in the API key from step 3.
-
 1. Save the configuration.
 
 ![Screenshot of Akismet settings](img/akismet_settings.png)
 
 ## Training
 
-> *Note:* Training the Akismet filter is only available in 8.11 and above.
+NOTE: **Note:**
+Training the Akismet filter is only available in GitLab 8.11 and later.
 
 As a way to better recognize between spam and ham, you can train the Akismet
 filter whenever there is a false positive or false negative.
diff --git a/doc/integration/azure.md b/doc/integration/azure.md
index 809a3b703fc..2059707e38c 100644
--- a/doc/integration/azure.md
+++ b/doc/integration/azure.md
@@ -2,33 +2,18 @@
 
 To enable the Microsoft Azure OAuth2 OmniAuth provider you must register your application with Azure. Azure will generate a client ID and secret key for you to use.
 
-1. Sign in to the [Azure Management Portal](https://portal.azure.com).
+Sign in to the [Azure Portal](https://portal.azure.com), and follow the instructions in
+the [Microsoft Quickstart documentation](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app).
 
-1. Select "Active Directory" on the left and choose the directory you want to use to register GitLab.
+As you go through the Microsoft procedure, keep the following in mind:
 
-1. Select "Applications" at the top bar and click the "Add" button the bottom.
-
-1. Select "Add an application my organization is developing".
-
-1. Provide the project information and click the "Next" button.
-   - Name: 'GitLab' works just fine here.
-   - Type: 'WEB APPLICATION AND/OR WEB API'
-
-1. On the "App properties" page enter the needed URI's and click the "Complete" button.
-   - SIGN-IN URL: Enter the URL of your GitLab installation (e.g `https://gitlab.mycompany.com/`)
-   - APP ID URI: Enter the endpoint URL for Microsoft to use, just has to be unique (e.g `https://mycompany.onmicrosoft.com/gitlab`)
-
-1. Select "Configure" in the top menu.
-
-1. Add a "Reply URL" pointing to the Azure OAuth callback of your GitLab installation (e.g. `https://gitlab.mycompany.com/users/auth/azure_oauth2/callback`).
-
-1. Create a "Client secret" by selecting a duration, the secret will be generated as soon as you click the "Save" button in the bottom menu.
-
-1. Note the "CLIENT ID" and the "CLIENT SECRET".
-
-1. Select "View endpoints" from the bottom menu.
-
-1. You will see lots of endpoint URLs in the form `https://login.microsoftonline.com/TENANT ID/...`, note down the TENANT ID part of one of those endpoints.
+- If you have multiple instances of Azure Active Directory, you can switch to the desired tenant.
+- You're setting up a Web application.
+- For the redirect URI, you'll need the URL of the Azure OAuth callback of your GitLab installation (for example, `https://gitlab.mycompany.com/users/auth/azure_oauth2/callback`). The type dropdown should be set to "Web".
+- The `client ID` and `client secret` are terms associated with OAuth 2. In some Microsoft documentation,
+  the terms may be listed as `Application ID` and `Application Secret`.
+- If you need to generate a new client secret, follow the Microsoft documentation on how to [Create a new application secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal#create-a-new-application-secret).
+- Save the client ID and client secret for your new app. Once you leave the Azure portal, you won't be able to find the client secret again.
 
 1. On your GitLab server, open the configuration file.
 
@@ -84,4 +69,7 @@ To enable the Microsoft Azure OAuth2 OmniAuth provider you must register your ap
 1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect if you
    installed GitLab via Omnibus or from source respectively.
 
-On the sign in page there should now be a Microsoft icon below the regular sign in form. Click the icon to begin the authentication process. Microsoft will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in.
+On the sign-in page, you should now see a Microsoft icon below the regular sign in form. Click the icon
+to begin the authentication process. Microsoft then asks you to sign in and authorize the GitLab application. If everything goes well, you are returned to GitLab and signed in.
+See [Enable OmniAuth for an Existing User](omniauth.md#enable-omniauth-for-an-existing-user)
+for information on how existing GitLab users can connect to their newly-available Azure AD accounts.
diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md
index ae9d5bd8f60..07ef5dbb99d 100644
--- a/doc/integration/elasticsearch.md
+++ b/doc/integration/elasticsearch.md
@@ -54,7 +54,7 @@ The way you install the Go indexer depends on your version of GitLab:
 ### Omnibus GitLab
 
 Since GitLab 11.8 the Go indexer is included in Omnibus GitLab.
-The former Ruby-based indexer was removed in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/issues/6481).
+The former Ruby-based indexer was removed in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/-/issues/6481).
 
 ### From source
 
@@ -142,6 +142,7 @@ The following Elasticsearch settings are available:
 | Parameter                                             | Description |
 | ----------------------------------------------------- | ----------- |
 | `Elasticsearch indexing`                              | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special Rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
+| `Elasticsearch pause indexing`                        | Enables/disables temporary indexing pause. This is useful for cluster migration/reindexing. All changes are still tracked, but they are not committed to the Elasticsearch index until unpaused. |
 | `Search with Elasticsearch enabled`                   | Enables/disables using Elasticsearch in search. |
 | `URL`                                                 | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
 | `Number of Elasticsearch shards`                      | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) |
@@ -418,14 +419,14 @@ The following are some available Rake tasks:
 | [`sudo gitlab-rake gitlab:elastic:index_projects`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)                   | Iterates over all projects and queues Sidekiq jobs to index them in the background.                                                                                                       |
 | [`sudo gitlab-rake gitlab:elastic:index_projects_status`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)            | Determines the overall status of the indexing. It is done by counting the total number of indexed projects, dividing by a count of the total number of projects, then multiplying by 100. |
 | [`sudo gitlab-rake gitlab:elastic:clear_index_status`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)               | Deletes all instances of IndexStatus for all projects.                                                                                                                                    |
-| [`sudo gitlab-rake gitlab:elastic:create_empty_index[<INDEX_NAME>]`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Generates an empty index on the Elasticsearch side only if it doesn't already exist.                                                                                                      |
-| [`sudo gitlab-rake gitlab:elastic:delete_index[<INDEX_NAME>]`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)       | Removes the GitLab index on the Elasticsearch instance.                                                                                                                                   |
-| [`sudo gitlab-rake gitlab:elastic:recreate_index[<INDEX_NAME>]`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)     | Wrapper task for `gitlab:elastic:delete_index[<INDEX_NAME>]` and `gitlab:elastic:create_empty_index[<INDEX_NAME>]`.                                                                       |
+| [`sudo gitlab-rake gitlab:elastic:create_empty_index[<TARGET_NAME>]`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Generates an empty index and assigns an alias for it on the Elasticsearch side only if it doesn't already exist.                                                                                                      |
+| [`sudo gitlab-rake gitlab:elastic:delete_index[<TARGET_NAME>]`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)       | Removes the GitLab index and alias (if exists) on the Elasticsearch instance.                                                                                                                                   |
+| [`sudo gitlab-rake gitlab:elastic:recreate_index[<TARGET_NAME>]`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)     | Wrapper task for `gitlab:elastic:delete_index[<TARGET_NAME>]` and `gitlab:elastic:create_empty_index[<TARGET_NAME>]`.                                                                       |
 | [`sudo gitlab-rake gitlab:elastic:index_snippets`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)                   | Performs an Elasticsearch import that indexes the snippets data.                                                                                                                          |
 | [`sudo gitlab-rake gitlab:elastic:projects_not_indexed`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)             | Displays which projects are not indexed.                                                                                                                                                  |
 
 NOTE: **Note:**
-The `INDEX_NAME` parameter is optional and will use the default index name from the current `RAILS_ENV` if not set.
+The `TARGET_NAME` parameter is optional and will use the default index/alias name from the current `RAILS_ENV` if not set.
 
 ### Environment variables
 
@@ -511,7 +512,9 @@ Here are some common pitfalls and how to overcome them:
   pp s.search_objects.class.name
   ```
 
-  If you see `Elasticsearch::Model::Response::Records`, you are using Elasticsearch.
+  If you see `"ActiveRecord::Relation"`, you are **not** using Elasticsearch.
+  
+  If you see `"Kaminari::PaginatableArray"` you are using Elasticsearch.
 
   NOTE: **Note**:
   The above instructions are used to verify that GitLab is using Elasticsearch only when indexing all namespaces. This is not to be used for scenarios that only index a [subset of namespaces](#limiting-namespaces-and-projects).
@@ -627,13 +630,13 @@ Here are some common pitfalls and how to overcome them:
    You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticsearch Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a).
    Once you have corrected the formatting of the URL, delete the index (via the [dedicated Rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index).
 
-### Low level troubleshooting
+### Low-level troubleshooting
 
-There is more [low level troubleshooting documentation](../administration/troubleshooting/elasticsearch.md) for when you experience other issues, including poor performance.
+There is a [more structured, lower-level troubleshooting document](../administration/troubleshooting/elasticsearch.md) for when you experience other issues, including poor performance.
 
 ### Known Issues
 
-- **[Elasticsearch `code_analyzer` doesn't account for all code cases](https://gitlab.com/gitlab-org/gitlab/issues/10693)**
+- **[Elasticsearch `code_analyzer` doesn't account for all code cases](https://gitlab.com/gitlab-org/gitlab/-/issues/10693)**
 
    The `code_analyzer` pattern and filter configuration is being evaluated for improvement. We have noticed [several edge cases](https://gitlab.com/gitlab-org/gitlab/-/issues/10693#note_158382332) that are not returning expected search results due to our pattern and filter configuration.
 
diff --git a/doc/integration/gmail_action_buttons_for_gitlab.md b/doc/integration/gmail_action_buttons_for_gitlab.md
index 1ab01494edc..526db8a7338 100644
--- a/doc/integration/gmail_action_buttons_for_gitlab.md
+++ b/doc/integration/gmail_action_buttons_for_gitlab.md
@@ -21,4 +21,4 @@ In particular, note:
 - Emails must be authenticated via DKIM or SPF.
 - Before sending the final form ("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you will have to find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there.
 
-You can check how it looks going through all the steps laid out in the "Registering with Google" doc in [this GitLab.com issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/1517).
+You can check how it looks going through all the steps laid out in the "Registering with Google" doc in [this GitLab.com issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/1517).
diff --git a/doc/integration/img/ultra_auth_credentials.png b/doc/integration/img/ultra_auth_credentials.png
deleted file mode 100644
index cff98a4b056..00000000000
--- a/doc/integration/img/ultra_auth_credentials.png
+++ /dev/null
diff --git a/doc/integration/img/ultra_auth_edit_callback_url.png b/doc/integration/img/ultra_auth_edit_callback_url.png
deleted file mode 100644
index b7548122c5e..00000000000
--- a/doc/integration/img/ultra_auth_edit_callback_url.png
+++ /dev/null
diff --git a/doc/integration/img/ultra_auth_edit_callback_url_highlighted.png b/doc/integration/img/ultra_auth_edit_callback_url_highlighted.png
deleted file mode 100644
index 4abf224756c..00000000000
--- a/doc/integration/img/ultra_auth_edit_callback_url_highlighted.png
+++ /dev/null
diff --git a/doc/integration/jira_development_panel.md b/doc/integration/jira_development_panel.md
index e9b1c9676bd..f032345b9e0 100644
--- a/doc/integration/jira_development_panel.md
+++ b/doc/integration/jira_development_panel.md
@@ -1,6 +1,6 @@
 # GitLab Jira development panel integration **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2381) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2381) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.0.
 
 Complementary to our [existing Jira](../user/project/integrations/jira.md) project integration, you're now able to integrate
 GitLab projects with [Jira Development Panel](https://confluence.atlassian.com/adminjiraserver070/). Both can be used
@@ -173,8 +173,8 @@ Click the links to see your GitLab repository data.
 
 ### 11.10
 
-- [Instance admins can now setup integration for all namespaces](https://gitlab.com/gitlab-org/gitlab/issues/8902)
+- [Instance admins can now setup integration for all namespaces](https://gitlab.com/gitlab-org/gitlab/-/issues/8902)
 
 ### 11.1
 
-- [Support GitLab subgroups in Jira development panel](https://gitlab.com/gitlab-org/gitlab/issues/3561)
+- [Support GitLab subgroups in Jira development panel](https://gitlab.com/gitlab-org/gitlab/-/issues/3561)
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index 01bd2a8c0a0..56f7b50496c 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -98,12 +98,12 @@ successful.
 
 ## Linking Kerberos and LDAP accounts together
 
-If your users log in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap.md)
+If your users log in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap/index.md)
 enabled, then your users will be automatically linked to their LDAP accounts on
 first login. For this to work, some prerequisites must be met:
 
 The Kerberos username must match the LDAP user's UID. You can choose which LDAP
-attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap.md#configuration)
+attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap/index.md#configuration-core-only)
 but for Active Directory, this should be `sAMAccountName`.
 
 The Kerberos realm must match the domain part of the LDAP user's Distinguished
diff --git a/doc/integration/ldap.md b/doc/integration/ldap.md
index 76c124d2ce9..25e4cc52375 100644
--- a/doc/integration/ldap.md
+++ b/doc/integration/ldap.md
@@ -1,5 +1,5 @@
 ---
-redirect_to: '../administration/auth/ldap.md'
+redirect_to: '../administration/auth/ldap/index.md'
 ---
 
-This document was moved to [`administration/auth/ldap`](../administration/auth/ldap.md).
+This document was moved to [`administration/auth/ldap`](../administration/auth/ldap/index.md).
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md
index 2afdeccb764..2ace05a8320 100644
--- a/doc/integration/omniauth.md
+++ b/doc/integration/omniauth.md
@@ -34,7 +34,6 @@ contains some settings that are common for all providers.
 - [OAuth2Generic](oauth2_generic.md)
 - [JWT](../administration/auth/jwt.md)
 - [OpenID Connect](../administration/auth/oidc.md)
-- [UltraAuth](ultra_auth.md)
 - [Salesforce](salesforce.md)
 - [AWS Cognito](../administration/auth/cognito.md)
 
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index 5cb57baf353..97384d8f6cf 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -1,4 +1,4 @@
-# SAML OmniAuth Provider
+# SAML OmniAuth Provider **(CORE ONLY)**
 
 Note that:
 
diff --git a/doc/integration/ultra_auth.md b/doc/integration/ultra_auth.md
deleted file mode 100644
index 95f2c0feb3b..00000000000
--- a/doc/integration/ultra_auth.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# UltraAuth OmniAuth Provider
-
-You can integrate your GitLab instance with [UltraAuth](https://github.com/ultraauth) to enable users to perform secure biometric authentication to your GitLab instance with your UltraAuth account. Users have to perform the biometric authentication using their mobile device with fingerprint sensor.
-
-## Create UltraAuth Application
-
-To enable UltraAuth OmniAuth provider, you must use UltraAuth's credentials for your GitLab instance.
-To get the credentials (a pair of Client ID and Client Secret), you must register an application on UltraAuth.
-
-1. Sign in to [UltraAuth](https://app.ultraauth.com).
-1. Navigate to **Create an App** and click on **Ruby on Rails**.
-1. Scroll down the page that is displayed to locate the **Client ID** and **Client Secret**.
-   Keep this page open as you continue configuration.
-
-   ![UltraAuth Credentials: OPENID_CLIENT_ID and OPENID_CLIENT_SECRET](img/ultra_auth_credentials.png)
-
-1. Click on "Edit Callback URL" link.
-
-   ![Edit UltraAuth Callback URL](img/ultra_auth_edit_callback_url_highlighted.png)
-
-1. The callback URL will be `http(s)://<your_domain>/users/auth/ultraauth/callback`
-
-   ![UltraAuth Callback URL](img/ultra_auth_edit_callback_url.png)
-
-1. Select **Register application**.
-1. On your GitLab server, open the configuration file.
-
-   For Omnibus package:
-
-   ```shell
-   sudo editor /etc/gitlab/gitlab.rb
-   ```
-
-   For installations from source:
-
-   ```shell
-   cd /home/git/gitlab
-   sudo -u git -H editor config/gitlab.yml
-   ```
-
-1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
-1. Add the provider configuration:
-
-   For Omnibus package:
-
-   ```ruby
-   gitlab_rails['omniauth_providers'] = [
-     {
-       "name" => "ultraauth",
-       "app_id" => "OPENID_CLIENT_ID",
-       "app_secret" => "OPENID_CLIENT_SECRET",
-       "args" => {
-         "client_options" => {
-           "redirect_uri" => "https://example.com/users/auth/ultraauth/callback"
-         }
-       }
-     }
-   ]
-   ```
-
-   For installation from source:
-
-   ```yaml
-   - { name: 'ultraauth',
-       app_id: 'OPENID_CLIENT_ID',
-       app_secret: 'OPENID_CLIENT_SECRET',
-       args: {
-         client_options: {
-           redirect_uri: 'https://example.com/users/auth/ultraauth/callback'
-         }
-       }
-     }
-   ```
-
-   __Replace `https://example.com/users/auth/ultraauth/callback` with your application's Callback URL.__
-
-1. Change `OPENID_CLIENT_ID` to the Client ID from the UltraAuth application page.
-1. Change `OPENID_CLIENT_SECRET` to the Client Secret from the UltraAuth application page.
-1. Save the configuration file.
-1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect if you
-   installed GitLab via Omnibus or from source respectively.
-
-On the sign in page, there should now be an UltraAuth icon below the regular sign in form.
-Click the icon to begin the authentication process. UltraAuth will ask the user to sign in and authorize the GitLab application.
-If everything goes well, the user will be returned to GitLab and will be signed in.
-
-GitLab requires the email address of each new user. Once the user is logged in using UltraAuth, GitLab will redirect the user to the profile page where they will have to provide the email and verify the email. Password authentication will be disabled for UltraAuth users and two-factor authentication (2FA) will be enforced.
diff --git a/doc/integration/vault.md b/doc/integration/vault.md
index 0a6ced42925..cead8f7592a 100644
--- a/doc/integration/vault.md
+++ b/doc/integration/vault.md
@@ -7,7 +7,7 @@ type: reference, howto
 
 # Vault Authentication with GitLab OpenID Connect
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/22323) in GitLab 9.0
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22323) in GitLab 9.0
 
 [Vault](https://www.vaultproject.io/) is a secrets management application offered by HashiCorp.
 It allows you to store and manage sensitive information such as secret environment variables, encryption keys, and authentication tokens.
@@ -21,7 +21,7 @@ The following assumes you already have Vault installed and running.
    First you'll need to create a GitLab application to obtain an application ID and secret for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
 
    1. On GitLab, click your avatar on the top-right corner, and select your user **Settings > Applications**.
-   1. Fill out the application **Name** and [**Redirect URI**](https://www.vaultproject.io/docs/auth/jwt/#redirect-uris),
+   1. Fill out the application **Name** and [**Redirect URI**](https://www.vaultproject.io/docs/auth/jwt#redirect-uris),
       making sure to select the **OpenID** scope.
    1. Save application.
    1. Copy client ID and secret, or keep the page open for reference.
@@ -69,7 +69,7 @@ The following assumes you already have Vault installed and running.
 
 1. **Write the OIDC Role Config:**
 
-   Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt/#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
+   Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
 
    This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI.
 
@@ -110,7 +110,7 @@ The following assumes you already have Vault installed and running.
 
    1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
    1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
-   1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt/#redirect-uris).
+   1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
 
    Once you run the command above, it will present a link in the terminal.
    Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC: