Commit 33c734e4 authored by Marcel Amirault's avatar Marcel Amirault

Fix spacing of codeblocks in various docs

Without proper spacing, codeblocks will not color
correctly, so this aligns all codeblocks with the
list items they are nested beneath
parent addcbdc3
...@@ -86,9 +86,9 @@ Now that the Okta app is configured, it's time to enable it in GitLab. ...@@ -86,9 +86,9 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
Edit `config/gitlab.yml`: Edit `config/gitlab.yml`:
```yaml ```yaml
auto_link_saml_user: true auto_link_saml_user: true
``` ```
1. Add the provider configuration. 1. Add the provider configuration.
......
...@@ -167,7 +167,7 @@ sudo gitlab-rake gitlab:geo:check ...@@ -167,7 +167,7 @@ sudo gitlab-rake gitlab:geo:check
``` ```
- Ensure that you have the `gitlab_rails['db_password']` set to the plain text-password used when creating the hash for `postgresql['sql_user_password']`. - Ensure that you have the `gitlab_rails['db_password']` set to the plain text-password used when creating the hash for `postgresql['sql_user_password']`.
```
1. Rails is unable to connect to the database 1. Rails is unable to connect to the database
```plaintext ```plaintext
......
...@@ -121,7 +121,7 @@ node, using `psql` which is installed by GitLab Omnibus. ...@@ -121,7 +121,7 @@ node, using `psql` which is installed by GitLab Omnibus.
```sql ```sql
CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD 'PRAEFECT_SQL_PASSWORD'; CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD 'PRAEFECT_SQL_PASSWORD';
``` ```
1. Reconnect to the PostgreSQL server, this time as the `praefect` user: 1. Reconnect to the PostgreSQL server, this time as the `praefect` user:
......
...@@ -135,9 +135,9 @@ To use an external Prometheus server: ...@@ -135,9 +135,9 @@ To use an external Prometheus server:
1. Install and set up a dedicated Prometheus instance, if necessary, using the [official installation instructions](https://prometheus.io/docs/prometheus/latest/installation/). 1. Install and set up a dedicated Prometheus instance, if necessary, using the [official installation instructions](https://prometheus.io/docs/prometheus/latest/installation/).
1. Add the Prometheus server IP address to the [monitoring IP whitelist](../ip_whitelist.md). For example: 1. Add the Prometheus server IP address to the [monitoring IP whitelist](../ip_whitelist.md). For example:
```ruby ```ruby
gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1'] gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
``` ```
1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server 1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server
IP. For example: IP. For example:
......
...@@ -360,16 +360,16 @@ that method from working. Use the following workaround: ...@@ -360,16 +360,16 @@ that method from working. Use the following workaround:
1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL 1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
```shell ```shell
printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
echo -n | openssl s_client -connect gitlab-domain-example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem echo -n | openssl s_client -connect gitlab-domain-example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
``` ```
1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances: 1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances:
```shell ```shell
sudo gitlab-ctl restart gitlab-pages sudo gitlab-ctl restart gitlab-pages
``` ```
CAUTION: **Caution:** CAUTION: **Caution:**
Some GitLab Omnibus upgrades will revert this workaround and you'll need to apply it again. Some GitLab Omnibus upgrades will revert this workaround and you'll need to apply it again.
......
...@@ -63,158 +63,158 @@ other CDNs or Function as a Service (FaaS) systems should work using the same pr ...@@ -63,158 +63,158 @@ other CDNs or Function as a Service (FaaS) systems should work using the same pr
`pwgen -cn1 64` on a UNIX machine). Save this token for the admin panel, as `pwgen -cn1 64` on a UNIX machine). Save this token for the admin panel, as
described in the [configuring](#configuring) section. described in the [configuring](#configuring) section.
```js ```js
const ORIGIN_HOSTNAME = 'gitlab.installation.com' // FIXME: SET CORRECT VALUE const ORIGIN_HOSTNAME = 'gitlab.installation.com' // FIXME: SET CORRECT VALUE
const STORAGE_TOKEN = 'very-secure-token' // FIXME: SET CORRECT VALUE const STORAGE_TOKEN = 'very-secure-token' // FIXME: SET CORRECT VALUE
const CACHE_PRIVATE_OBJECTS = false const CACHE_PRIVATE_OBJECTS = false
const CORS_HEADERS = { const CORS_HEADERS = {
'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'GET, HEAD, OPTIONS', 'Access-Control-Allow-Methods': 'GET, HEAD, OPTIONS',
'Access-Control-Allow-Headers': 'X-Csrf-Token, X-Requested-With', 'Access-Control-Allow-Headers': 'X-Csrf-Token, X-Requested-With',
} }
self.addEventListener('fetch', event => event.respondWith(handle(event))) self.addEventListener('fetch', event => event.respondWith(handle(event)))
async function handle(event) { async function handle(event) {
try { try {
let response = await verifyAndHandle(event); let response = await verifyAndHandle(event);
// responses returned from cache are immutable, so we recreate them // responses returned from cache are immutable, so we recreate them
// to set CORS headers // to set CORS headers
response = new Response(response.body, response) response = new Response(response.body, response)
response.headers.set('Access-Control-Allow-Origin', '*') response.headers.set('Access-Control-Allow-Origin', '*')
return response return response
} catch (e) { } catch (e) {
return new Response('An error occurred!', {status: e.statusCode || 500}) return new Response('An error occurred!', {status: e.statusCode || 500})
} }
} }
async function verifyAndHandle(event) { async function verifyAndHandle(event) {
if (!validRequest(event.request)) { if (!validRequest(event.request)) {
return new Response(null, {status: 400}) return new Response(null, {status: 400})
} }
if (event.request.method === 'OPTIONS') { if (event.request.method === 'OPTIONS') {
return handleOptions(event.request) return handleOptions(event.request)
} }
return handleRequest(event) return handleRequest(event)
} }
function handleOptions(request) { function handleOptions(request) {
// Make sure the necessary headers are present // Make sure the necessary headers are present
// for this to be a valid pre-flight request // for this to be a valid pre-flight request
if ( if (
request.headers.get('Origin') !== null && request.headers.get('Origin') !== null &&
request.headers.get('Access-Control-Request-Method') !== null && request.headers.get('Access-Control-Request-Method') !== null &&
request.headers.get('Access-Control-Request-Headers') !== null request.headers.get('Access-Control-Request-Headers') !== null
) { ) {
// Handle CORS pre-flight request // Handle CORS pre-flight request
return new Response(null, { return new Response(null, {
headers: CORS_HEADERS, headers: CORS_HEADERS,
}) })
} else { } else {
// Handle standard OPTIONS request // Handle standard OPTIONS request
return new Response(null, { return new Response(null, {
headers: { headers: {
Allow: 'GET, HEAD, OPTIONS', Allow: 'GET, HEAD, OPTIONS',
}, },
}) })
} }
} }
async function handleRequest(event) { async function handleRequest(event) {
let cache = caches.default let cache = caches.default
let url = new URL(event.request.url) let url = new URL(event.request.url)
let static_object_token = url.searchParams.get('token') let static_object_token = url.searchParams.get('token')
let headers = new Headers(event.request.headers) let headers = new Headers(event.request.headers)
url.host = ORIGIN_HOSTNAME url.host = ORIGIN_HOSTNAME
url = normalizeQuery(url) url = normalizeQuery(url)
headers.set('X-Gitlab-External-Storage-Token', STORAGE_TOKEN) headers.set('X-Gitlab-External-Storage-Token', STORAGE_TOKEN)
if (static_object_token !== null) { if (static_object_token !== null) {
headers.set('X-Gitlab-Static-Object-Token', static_object_token) headers.set('X-Gitlab-Static-Object-Token', static_object_token)
} }
let request = new Request(url, { headers: headers }) let request = new Request(url, { headers: headers })
let cached_response = await cache.match(request) let cached_response = await cache.match(request)
let is_conditional_header_set = headers.has('If-None-Match') let is_conditional_header_set = headers.has('If-None-Match')
if (cached_response) { if (cached_response) {
return cached_response return cached_response
} }
// We don't want to override If-None-Match that is set on the original request // We don't want to override If-None-Match that is set on the original request
if (cached_response && !is_conditional_header_set) { if (cached_response && !is_conditional_header_set) {
headers.set('If-None-Match', cached_response.headers.get('ETag')) headers.set('If-None-Match', cached_response.headers.get('ETag'))
} }
let response = await fetch(request, { let response = await fetch(request, {
headers: headers, headers: headers,
redirect: 'manual' redirect: 'manual'
}) })
if (response.status == 304) { if (response.status == 304) {
if (is_conditional_header_set) { if (is_conditional_header_set) {
return response return response
} else { } else {
return cached_response return cached_response
} }
} else if (response.ok) { } else if (response.ok) {
response = new Response(response.body, response) response = new Response(response.body, response)
// cache.put will never cache any response with a Set-Cookie header // cache.put will never cache any response with a Set-Cookie header
response.headers.delete('Set-Cookie') response.headers.delete('Set-Cookie')
if (CACHE_PRIVATE_OBJECTS) { if (CACHE_PRIVATE_OBJECTS) {
response.headers.delete('Cache-Control') response.headers.delete('Cache-Control')
} }
event.waitUntil(cache.put(request, response.clone())) event.waitUntil(cache.put(request, response.clone()))
} }
return response return response
} }
function normalizeQuery(url) { function normalizeQuery(url) {
let searchParams = url.searchParams let searchParams = url.searchParams
url = new URL(url.toString().split('?')[0]) url = new URL(url.toString().split('?')[0])
if (url.pathname.includes('/raw/')) { if (url.pathname.includes('/raw/')) {
let inline = searchParams.get('inline') let inline = searchParams.get('inline')
if (inline == 'false' || inline == 'true') { if (inline == 'false' || inline == 'true') {
url.searchParams.set('inline', inline) url.searchParams.set('inline', inline)
} }
} else if (url.pathname.includes('/-/archive/')) { } else if (url.pathname.includes('/-/archive/')) {
let append_sha = searchParams.get('append_sha') let append_sha = searchParams.get('append_sha')
let path = searchParams.get('path') let path = searchParams.get('path')
if (append_sha == 'false' || append_sha == 'true') { if (append_sha == 'false' || append_sha == 'true') {
url.searchParams.set('append_sha', append_sha) url.searchParams.set('append_sha', append_sha)
} }
if (path) { if (path) {
url.searchParams.set('path', path) url.searchParams.set('path', path)
} }
} }
return url return url
} }
function validRequest(request) { function validRequest(request) {
let url = new URL(request.url) let url = new URL(request.url)
let path = url.pathname let path = url.pathname
if (/^(.+)(\/raw\/|\/-\/archive\/)/.test(path)) { if (/^(.+)(\/raw\/|\/-\/archive\/)/.test(path)) {
return true return true
} }
return false return false
} }
``` ```
1. Create a new worker with this script. 1. Create a new worker with this script.
1. Copy your values for `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`. 1. Copy your values for `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.
......
...@@ -202,9 +202,9 @@ and they will assist you with any issues you are having. ...@@ -202,9 +202,9 @@ and they will assist you with any issues you are having.
- How to get the manifest for a release. It can be useful because it contains the info about - How to get the manifest for a release. It can be useful because it contains the info about
all Kubernetes resources and dependent charts: all Kubernetes resources and dependent charts:
```shell ```shell
helm get manifest <release name> helm get manifest <release name>
``` ```
## Installation of minimal GitLab config via Minukube on macOS ## Installation of minimal GitLab config via Minukube on macOS
......
...@@ -127,14 +127,14 @@ not without its own challenges: ...@@ -127,14 +127,14 @@ not without its own challenges:
and use it as your mount point (for a more thorough explanation, check [issue and use it as your mount point (for a more thorough explanation, check [issue
#41227](https://gitlab.com/gitlab-org/gitlab-foss/issues/41227)): #41227](https://gitlab.com/gitlab-org/gitlab-foss/issues/41227)):
```yaml ```yaml
variables: variables:
MOUNT_POINT: /builds/$CI_PROJECT_PATH/mnt MOUNT_POINT: /builds/$CI_PROJECT_PATH/mnt
script: script:
- mkdir -p "$MOUNT_POINT" - mkdir -p "$MOUNT_POINT"
- docker run -v "$MOUNT_POINT:/mnt" my-docker-image - docker run -v "$MOUNT_POINT:/mnt" my-docker-image
``` ```
An example project using this approach can be found here: <https://gitlab.com/gitlab-examples/docker>. An example project using this approach can be found here: <https://gitlab.com/gitlab-examples/docker>.
...@@ -198,7 +198,7 @@ support this. ...@@ -198,7 +198,7 @@ support this.
[runners.cache] [runners.cache]
[runners.cache.s3] [runners.cache.s3]
[runners.cache.gcs] [runners.cache.gcs]
``` ```
1. You can now use `docker` in the build script (note the inclusion of the 1. You can now use `docker` in the build script (note the inclusion of the
`docker:19.03.1-dind` service): `docker:19.03.1-dind` service):
......
...@@ -22,22 +22,22 @@ limit values. It's recommended to create separate migration script files. ...@@ -22,22 +22,22 @@ limit values. It's recommended to create separate migration script files.
1. Add new column to the `plan_limits` table with non-null default value 0, eg: 1. Add new column to the `plan_limits` table with non-null default value 0, eg:
```ruby ```ruby
add_column(:plan_limits, :project_hooks, :integer, default: 0, null: false) add_column(:plan_limits, :project_hooks, :integer, default: 0, null: false)
``` ```
NOTE: **Note:** Plan limits entries set to `0` mean that limits are not NOTE: **Note:** Plan limits entries set to `0` mean that limits are not
enabled. enabled.
1. Insert plan limits values into the database using 1. Insert plan limits values into the database using
`create_or_update_plan_limit` migration helper, eg: `create_or_update_plan_limit` migration helper, eg:
```ruby ```ruby
create_or_update_plan_limit('project_hooks', 'free', 10) create_or_update_plan_limit('project_hooks', 'free', 10)
create_or_update_plan_limit('project_hooks', 'bronze', 20) create_or_update_plan_limit('project_hooks', 'bronze', 20)
create_or_update_plan_limit('project_hooks', 'silver', 30) create_or_update_plan_limit('project_hooks', 'silver', 30)
create_or_update_plan_limit('project_hooks', 'gold', 100) create_or_update_plan_limit('project_hooks', 'gold', 100)
``` ```
### Plan limits validation ### Plan limits validation
......
...@@ -70,9 +70,9 @@ this needs to happen when the stable branches for all products have been created ...@@ -70,9 +70,9 @@ this needs to happen when the stable branches for all products have been created
1. Run the raketask to create the single version: 1. Run the raketask to create the single version:
```shell ```shell
./bin/rake "release:single[12.0]" ./bin/rake "release:single[12.0]"
``` ```
A new `Dockerfile.12.0` should have been created and committed to a new branch. A new `Dockerfile.12.0` should have been created and committed to a new branch.
......
...@@ -115,13 +115,13 @@ The last option is to import a project using a Rails console: ...@@ -115,13 +115,13 @@ The last option is to import a project using a Rails console:
project: project).restore project: project).restore
``` ```
We are storing all import failures in the `import_failures` data table. We are storing all import failures in the `import_failures` data table.
To make sure that the project import finished without any issues, check: To make sure that the project import finished without any issues, check:
```ruby ```ruby
project.import_failures.all project.import_failures.all
``` ```
## Performance testing ## Performance testing
......
...@@ -15,106 +15,109 @@ The following assumes you already have Vault installed and running. ...@@ -15,106 +15,109 @@ The following assumes you already have Vault installed and running.
1. **Get the OpenID Connect client ID and secret from GitLab:** 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: 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. 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), 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. making sure to select the **OpenID** scope.
1. Save application. 1. Save application.
1. Copy client ID and secret, or keep the page open for reference. 1. Copy client ID and secret, or keep the page open for reference.
![GitLab OAuth provider](img/gitlab_oauth_vault_v12_6.png)
![GitLab OAuth provider](img/gitlab_oauth_vault_v12_6.png)
1. **Enable OIDC auth on Vault:** 1. **Enable OIDC auth on Vault:**
OpenID Connect is not enabled in Vault by default. This needs to be enabled in the terminal. 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: Open a terminal session and run the following command to enable the OpenID Connect authentication provider in Vault:
```shell ```shell
vault auth enable oidc vault auth enable oidc
``` ```
You should see the following output in the terminal: You should see the following output in the terminal:
```plaintext ```plaintext
Success! Enabled oidc auth method at: oidc/ Success! Enabled oidc auth method at: oidc/
``` ```
1. **Write the OIDC config:** 1. **Write the OIDC config:**
Next, Vault needs to be given the application ID and secret generated by GitLab. 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. 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: Replace `your_application_id` and `your_secret` in the example below with the application ID and secret generated for your app:
```shell ```shell
$ vault write auth/oidc/config \ $ vault write auth/oidc/config \
oidc_discovery_url="https://gitlab.com" \ oidc_discovery_url="https://gitlab.com" \
oidc_client_id="your_application_id" \ oidc_client_id="your_application_id" \
oidc_client_secret="your_secret" \ oidc_client_secret="your_secret" \
default_role="demo" \ default_role="demo" \
bound_issuer="localhost" bound_issuer="localhost"
``` ```
You should see the following output in the terminal: You should see the following output in the terminal:
```shell ```shell
Success! Data written to: auth/oidc/config Success! Data written to: auth/oidc/config
``` ```
1. **Write the OIDC Role 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: 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. 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.
```shell ```shell
vault write auth/oidc/role/demo \ vault write auth/oidc/role/demo \
user_claim="sub" \ user_claim="sub" \
allowed_redirect_uris="http://localhost:8250/oidc/callback,http://127.0.0.1:8200/ui/vault/auth/oidc/oidc/callback" \ 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" \ bound_audiences="your_application_id" \
role_type="oidc" \ role_type="oidc" \
oidc_scopes="openid" \ oidc_scopes="openid" \
policies=demo \ policies=demo \
ttl=1h ttl=1h
``` ```
1. **Sign in to Vault:** 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. 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. 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: 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)
![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.
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)
![Authorize Vault to connect with GitLab](img/authorize_vault_with_gitlab_v12_6.png)
1. **Sign in using the Vault CLI** (optional): 1. **Sign in using the Vault CLI** (optional):
Vault also allows you to sign in via their CLI. 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: 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:
```shell ```shell
vault login -method=oidc port=8250 role=demo vault login -method=oidc port=8250 role=demo
``` ```
Here is a short explaination of what this command does: 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. 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 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). 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. 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: 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) ![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)
The terminal will output: The terminal will output:
```plaintext ```plaintext
Success! You are now authenticated. The token information displayed below 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" is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token. again. Future Vault requests will automatically use this token.
``` ```
...@@ -270,9 +270,9 @@ image directly, follow these steps: ...@@ -270,9 +270,9 @@ image directly, follow these steps:
1. Run [Docker Desktop](https://www.docker.com/products/docker-desktop) or [Docker Machine](https://github.com/docker/machine). 1. Run [Docker Desktop](https://www.docker.com/products/docker-desktop) or [Docker Machine](https://github.com/docker/machine).
1. Run the latest [prefilled vulnerabilities database](https://cloud.docker.com/repository/docker/arminc/clair-db) Docker image: 1. Run the latest [prefilled vulnerabilities database](https://cloud.docker.com/repository/docker/arminc/clair-db) Docker image:
```shell ```shell
docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
``` ```
1. Configure an environment variable to point to your local machine's IP address (or insert your IP address instead of the `LOCAL_MACHINE_IP_ADDRESS` variable in the `CLAIR_DB_CONNECTION_STRING` in the next step): 1. Configure an environment variable to point to your local machine's IP address (or insert your IP address instead of the `LOCAL_MACHINE_IP_ADDRESS` variable in the `CLAIR_DB_CONNECTION_STRING` in the next step):
...@@ -282,16 +282,16 @@ image directly, follow these steps: ...@@ -282,16 +282,16 @@ image directly, follow these steps:
1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` environment variables: 1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` environment variables:
```shell ```shell
docker run \ docker run \
--interactive --rm \ --interactive --rm \
--volume "$PWD":/tmp/app \ --volume "$PWD":/tmp/app \
-e CI_PROJECT_DIR=/tmp/app \ -e CI_PROJECT_DIR=/tmp/app \
-e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \ -e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \
-e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \ -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
-e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \ -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
registry.gitlab.com/gitlab-org/security-products/analyzers/klar registry.gitlab.com/gitlab-org/security-products/analyzers/klar
``` ```
The results are stored in `gl-container-scanning-report.json`. The results are stored in `gl-container-scanning-report.json`.
......
...@@ -501,20 +501,20 @@ To install applications using GitLab CI: ...@@ -501,20 +501,20 @@ To install applications using GitLab CI:
1. Connect the cluster to a [cluster management project](management_project.md). 1. Connect the cluster to a [cluster management project](management_project.md).
1. In that project, add a `.gitlab-ci.yml` file with the following content: 1. In that project, add a `.gitlab-ci.yml` file with the following content:
```yaml ```yaml
include: include:
- template: Managed-Cluster-Applications.gitlab-ci.yml - template: Managed-Cluster-Applications.gitlab-ci.yml
``` ```
1. Add a `.gitlab/managed-apps/config.yaml` file to define which 1. Add a `.gitlab/managed-apps/config.yaml` file to define which
applications you would like to install. Define the `installed` key as applications you would like to install. Define the `installed` key as
`true` to install the application and `false` to uninstall the `true` to install the application and `false` to uninstall the
application. For example, to install Ingress: application. For example, to install Ingress:
```yaml ```yaml
ingress: ingress:
installed: true installed: true
``` ```
1. Optionally, define `.gitlab/managed-apps/<application>/values.yaml` file to 1. Optionally, define `.gitlab/managed-apps/<application>/values.yaml` file to
customize values for the installed application. customize values for the installed application.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment