Commit 5265f69b authored by Steve Azzopardi's avatar Steve Azzopardi

Add docs on how web terminals are secured

In the administration page for web terminals add a new `Security`
section explaining how the interactive web terminals are secured between
GitLab and gitlab-runner.

This section is under administration instead of
`doc/ci/interactive_web_terminal` because the administrators of the
GitLab instance would be mostly interested in this, whilst
`doc/ci/interactive_web_terminal` are interested in how the feature
works.

closes https://gitlab.com/gitlab-org/gitlab-ce/issues/52681
parent e216ac2c
...@@ -28,6 +28,19 @@ In brief: ...@@ -28,6 +28,19 @@ In brief:
user no longer has permission to access the terminal, or if the connection user no longer has permission to access the terminal, or if the connection
details have changed. details have changed.
## Security
GitLab and [GitLab Runner](https://docs.gitlab.com/runner/) take some
precautions to keep interactive web terminal data encrypted between them, and
everything protected with authorization guards. This is described in more
detail below.
- Interactive web terminals are completely disabled unless [`[session_server]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section) is configured.
- Every time the runner starts, it will generate an `x509` certificate that will be used for a `wss` (Web Socket Secure) connection.
- For every created job, a random URL is generated which is discarded at the end of the job. This URL is used to establish a web socket connection. The URL for the session is in the format `(IP|HOST):PORT/session/$SOME_HASH`, where the `IP/HOST` and `PORT` are the configured [`listen_address`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section).
- Every session URL that is created has an authorization header that needs to be sent, to establish a `wss` connection.
- The session URL is not exposed to the users in any way. GitLab holds all the state internally and proxies accordingly.
## Enabling and disabling terminal support ## Enabling and disabling terminal support
As web terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of As web terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of
......
...@@ -3,7 +3,10 @@ ...@@ -3,7 +3,10 @@
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/50144) in GitLab 11.3. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/50144) in GitLab 11.3.
Interactive web terminals give the user access to a terminal in GitLab for Interactive web terminals give the user access to a terminal in GitLab for
running one-off commands for their CI pipeline. running one-off commands for their CI pipeline. Since this is giving the user
shell access to the environment where [GitLab Runner](https://docs.gitlab.com/runner/)
is deployed, some [security precautions](../../administration/integration/terminal.md#security) were
taken to protect the users.
NOTE: **Note:** NOTE: **Note:**
GitLab.com does not support interactive web terminal at the moment – neither GitLab.com does not support interactive web terminal at the moment – neither
......
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