Add latest changes from gitlab-org/gitlab@master

9 files changed, 146 insertions, 8 deletions

diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md
index dad83b633a2..d411fb7f20f 100644
--- a/doc/administration/high_availability/README.md
+++ b/doc/administration/high_availability/README.md
@@ -4,18 +4,19 @@ type: reference, concepts
 
 # Scaling and High Availability
 
-GitLab supports several different types of clustering and high-availability.
+GitLab supports a number of options for scaling your self-managed instance and configuring high availability (HA).
 The solution you choose will be based on the level of scalability and
 availability you require. The easiest solutions are scalable, but not necessarily
 highly available.
 
-GitLab provides a service that is usually essential to most organizations: it
+GitLab provides a service that is essential to most organizations: it
 enables people to collaborate on code in a timely fashion. Any downtime should
-therefore be short and planned. Luckily, GitLab provides a solid setup even on
-a single server without special measures. Due to the distributed nature
-of Git, developers can still commit code locally even when GitLab is not
+therefore be short and planned. Due to the distributed nature
+of Git, developers can continue to commit code locally even when GitLab is not
 available. However, some GitLab features such as the issue tracker and
-Continuous Integration are not available when GitLab is down.
+continuous integration are not available when GitLab is down.
+If you require all GitLab functionality to be highly available,
+consider the options outlined below.
 
 **Keep in mind that all highly-available solutions come with a trade-off between
 cost/complexity and uptime**. The more uptime you want, the more complex the
@@ -25,8 +26,8 @@ solution should balance the costs against the benefits.
 
 There are many options when choosing a highly-available GitLab architecture. We
 recommend engaging with GitLab Support to choose the best architecture for your
-use case. This page contains some various options and guidelines based on
-experience with GitLab.com and Enterprise Edition on-premises customers.
+use case. This page contains recommendations based on
+experience with GitLab.com and internal scale testing.
 
 For detailed insight into how GitLab scales and configures GitLab.com, you can
 watch [this 1 hour Q&A](https://www.youtube.com/watch?v=uCU8jdYzpac)
diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md
index 9f95080654f..6f3c6028f71 100644
--- a/doc/administration/restart_gitlab.md
+++ b/doc/administration/restart_gitlab.md
@@ -8,6 +8,7 @@ If you want the TL;DR versions, jump to:
 - [Omnibus GitLab restart](#omnibus-gitlab-restart)
 - [Omnibus GitLab reconfigure](#omnibus-gitlab-reconfigure)
 - [Source installation restart](#installations-from-source)
+- [Helm chart installation restart](#helm-chart-installations)
 
 ## Omnibus installations
 
@@ -143,3 +144,16 @@ If you are using other init systems, like systemd, you can check the
 [chef]: https://www.chef.io/products/chef-infra/ "Chef official website"
 [src-service]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab "GitLab init service file"
 [gl-recipes]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init "GitLab Recipes repository"
+
+## Helm chart installations
+
+There is no single command to restart the entire GitLab application installed via
+the [cloud native Helm Chart](https://docs.gitlab.com/charts/). Usually, it should be
+enough to restart a specific component separately (`gitaly`, `unicorn`,
+`workhorse`, `gitlab-shell`, etc.) by deleting all the pods related to it:
+
+```bash
+kubectl delete pods -l release=<helm release name>,app=<component name>
+```
+
+The release name can be obtained from the output of the `helm list` command.
diff --git a/doc/api/pipelines.md b/doc/api/pipelines.md
index 97dc316cc96..e1b2c12dd00 100644
--- a/doc/api/pipelines.md
+++ b/doc/api/pipelines.md
@@ -18,6 +18,8 @@ GET /projects/:id/pipelines
 | `yaml_errors`| boolean  | no       | Returns pipelines with invalid configurations |
 | `name`| string  | no       | The name of the user who triggered pipelines |
 | `username`| string  | no       | The username of the user who triggered pipelines |
+| `updated_after` | datetime | no | Return pipelines updated after the specified date. Format: ISO 8601 YYYY-MM-DDTHH:MM:SSZ |
+| `updated_before` | datetime | no | Return pipelines updated before the specified date. Format: ISO 8601 YYYY-MM-DDTHH:MM:SSZ |
 | `order_by`| string  | no       | Order pipelines by `id`, `status`, `ref`, `updated_at` or `user_id` (default: `id`) |
 | `sort`    | string  | no       | Sort pipelines in `asc` or `desc` order (default: `desc`) |
 
diff --git a/doc/integration/README.md b/doc/integration/README.md
index 3f33aa94cb9..5cda537ac39 100644
--- a/doc/integration/README.md
+++ b/doc/integration/README.md
@@ -30,6 +30,7 @@ GitLab can be configured to authenticate access requests with the following auth
 - Use [OmniAuth](omniauth.md) to enable sign in via Twitter, GitHub, GitLab.com, Google,
 Bitbucket, Facebook, Shibboleth, SAML, Crowd, Azure or Authentiq ID.
 - Use GitLab as an [OpenID Connect](openid_connect_provider.md) identity provider.
+- Authenticate to [Vault](vault.md) through GitLab OpenID Connect.
 - Configure GitLab as a [SAML](saml.md) 2.0 Service Provider.
 
 ## Security enhancements
diff --git a/doc/integration/img/authorize_vault_with_gitlab_v12_6.png b/doc/integration/img/authorize_vault_with_gitlab_v12_6.png
new file mode 100644
index 00000000000..dc5bc954cd7
--- /dev/null
+++ b/doc/integration/img/authorize_vault_with_gitlab_v12_6.png
diff --git a/doc/integration/img/gitlab_oauth_vault_v12_6.png b/doc/integration/img/gitlab_oauth_vault_v12_6.png
new file mode 100644
index 00000000000..f952abc2c6d
--- /dev/null
+++ b/doc/integration/img/gitlab_oauth_vault_v12_6.png
diff --git a/doc/integration/img/sign_into_vault_with_gitlab_v12_6.png b/doc/integration/img/sign_into_vault_with_gitlab_v12_6.png
new file mode 100644
index 00000000000..8afa2c6aabd
--- /dev/null
+++ b/doc/integration/img/sign_into_vault_with_gitlab_v12_6.png
diff --git a/doc/integration/img/signed_into_vault_via_oidc_v12_6.png b/doc/integration/img/signed_into_vault_via_oidc_v12_6.png
new file mode 100644
index 00000000000..0ad81ef40e6
--- /dev/null
+++ b/doc/integration/img/signed_into_vault_via_oidc_v12_6.png
diff --git a/doc/integration/vault.md b/doc/integration/vault.md
new file mode 100644
index 00000000000..4aca62b5fd1
--- /dev/null
+++ b/doc/integration/vault.md
@@ -0,0 +1,120 @@
+---
+type: reference, howto
+---
+
+# Vault Authentication with GitLab OpenID Connect
+
+> [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 secret environment variables, encryption keys, and authentication tokens.
+Vault offers Identity-based Access, which means Vault users can authenticate through several of their preferred cloud providers.
+
+In this document, we'll explain how Vault users can authenticate themselves through GitLab by utilizing our OpenID authentication feature.
+The following assumes you already have Vault installed and running.
+
+1. **Get the OpenID Connect client ID and secret from GitLab:**
+
+    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.html#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.
+    ![GitLab OAuth provider](img/gitlab_oauth_vault_v12_6.png)
+
+1. **Enable OIDC auth on Vault:**
+
+    OpenID Connect is not enabled in Vault by default. This needs to be enabled in the terminal.
+
+    Open a terminal session and run the following command to enable the OpenID Connect authentication provider in Vault:
+
+    ```bash
+    vault auth enable oidc
+    ```
+
+    You should see the following output in the terminal:
+
+    ```bash
+    Success! Enabled oidc auth method at: oidc/
+    ```
+
+1. **Write the OIDC config:**
+
+    Next, Vault needs to be given the application ID and secret generated by Gitlab.
+
+    In the terminal session, run the following command to give Vault access to the GitLab application you've just created with an OpenID scope. This allows Vault to authenticate through GitLab.
+
+    Replace `your_application_id` and `your_secret` in the example below with the application ID and secret generated for your app:
+
+    ```bash
+    $ vault write auth/oidc/config \
+        oidc_discovery_url="https://gitlab.com" \
+        oidc_client_id="your_application_id" \
+        oidc_client_secret="your_secret" \
+        default_role="demo" \
+        bound_issuer="localhost"
+    ```
+
+    You should see the following output in the terminal:
+
+    ```bash
+    Success! Data written to: auth/oidc/config
+    ```
+
+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.html#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.
+
+    ```bash
+    vault write auth/oidc/role/demo \
+          user_claim="sub" \
+          allowed_redirect_uris="http://localhost:8250/oidc/callback,http://127.0.0.1:8200/ui/vault/auth/oidc/oidc/callback" \
+          bound_audiences="your_application_id" \
+          role_type="oidc" \
+          oidc_scopes="openid" \
+          policies=demo \
+          ttl=1h
+    ```
+
+1. **Sign in to Vault:**
+
+    1. Go to your Vault UI (example: [http://127.0.0.1:8200/ui/vault/auth?with=oidc](http://127.0.0.1:8200/ui/vault/auth?with=oidc)).
+    1. If the `OIDC` method is not currently selected, open the dropdown and select it.
+    1. Click the **Sign in With GitLab** button, which will open a modal window:
+    ![Sign into Vault with GitLab](img/sign_into_vault_with_gitlab_v12_6.png)
+
+    1. Click **Authorize** on the modal to allow Vault to sign in through GitLab. This will redirect you back to your Vault UI as a signed-in user.
+    ![Authorize Vault to connect with GitLab](img/authorize_vault_with_gitlab_v12_6.png)
+
+1. **Sign in using the Vault CLI** (optional):
+
+    Vault also allows you to sign in via their CLI.
+
+    After writing the same configurations from above, you can run the command below in your terminal to sign in with the role configuration created in step 4 above:
+
+    ```bash
+    vault login -method=oidc port=8250 role=demo
+    ```
+
+    Here is a short explaination of what this command does:
+
+    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.html#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:
+
+    ![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)
+
+    The terminal will output:
+
+    ```
+    Success! You are now authenticated. The token information displayed below
+    is already stored in the token helper. You do NOT need to run "vault login"
+    again. Future Vault requests will automatically use this token.
+    ```