diff options
Diffstat (limited to 'doc/security')
| -rw-r--r-- | doc/security/password_length_limits.md | 2 | ||||
| -rw-r--r-- | doc/security/rack_attack.md | 2 | ||||
| -rw-r--r-- | doc/security/rate_limits.md | 1 | ||||
| -rw-r--r-- | doc/security/ssh_keys_restrictions.md | 14 | ||||
| -rw-r--r-- | doc/security/token_overview.md | 6 | ||||
| -rw-r--r-- | doc/security/two_factor_authentication.md | 57 | ||||
| -rw-r--r-- | doc/security/user_email_confirmation.md | 2 | ||||
| -rw-r--r-- | doc/security/webhooks.md | 8 |
8 files changed, 55 insertions, 37 deletions
diff --git a/doc/security/password_length_limits.md b/doc/security/password_length_limits.md index 847656d8d17..bedf2ac3ab1 100644 --- a/doc/security/password_length_limits.md +++ b/doc/security/password_length_limits.md @@ -30,7 +30,7 @@ The user password length is set to a minimum of 8 characters by default. To change the minimum password length using GitLab UI: -1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the top bar, select **Menu > Admin**. 1. On the left sidebar, select **Settings > General** and expand **Sign-up restrictions**.  diff --git a/doc/security/rack_attack.md b/doc/security/rack_attack.md index 6d2725d1ec1..4894af1fa19 100644 --- a/doc/security/rack_attack.md +++ b/doc/security/rack_attack.md @@ -109,7 +109,7 @@ The following settings can be configured: - `enabled`: By default this is set to `false`. Set this to `true` to enable Rack Attack. - `ip_whitelist`: Whitelist any IPs from being blocked. They must be formatted as strings within a Ruby array. - CIDR notation is supported in GitLab v12.1 and up. + CIDR notation is supported in GitLab 12.1 and later. For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"]`. - `maxretry`: The maximum amount of times a request can be made in the specified time. diff --git a/doc/security/rate_limits.md b/doc/security/rate_limits.md index e698341b4b5..6045dece0c2 100644 --- a/doc/security/rate_limits.md +++ b/doc/security/rate_limits.md @@ -34,6 +34,7 @@ These are rate limits you can set in the Admin Area of your instance: - [Raw endpoints rate limits](../user/admin_area/settings/rate_limits_on_raw_endpoints.md) - [User and IP rate limits](../user/admin_area/settings/user_and_ip_rate_limits.md) - [Package registry rate limits](../user/admin_area/settings/package_registry_rate_limits.md) +- [Git LFS rate limits](../user/admin_area/settings/git_lfs_rate_limits.md) ## Non-configurable limits diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md index 55eeaae5458..239949b5568 100644 --- a/doc/security/ssh_keys_restrictions.md +++ b/doc/security/ssh_keys_restrictions.md @@ -5,7 +5,7 @@ group: Access info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# Restrict allowed SSH key technologies and minimum length +# Restrict allowed SSH key technologies and minimum length **(FREE SELF)** `ssh-keygen` allows users to create RSA keys with as few as 768 bits, which falls well below recommendations from certain standards groups (such as the US @@ -20,7 +20,7 @@ algorithms. GitLab allows you to restrict the allowed SSH key technology as well as specify the minimum key length for each technology: -1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the top bar, select **Menu > Admin**. 1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`). 1. Expand the **Visibility and access controls** section: @@ -36,6 +36,16 @@ An icon is visible to the user of a restricted key in the SSH keys section of th Hovering over this icon tells you why the key is restricted. +## Default settings + +By default, the GitLab.com and self-managed settings for the +[supported key types](../ssh/index.md#supported-ssh-key-types) are: + +- RSA SSH keys are allowed. +- DSA SSH keys are forbidden ([since GitLab 11.0](https://about.gitlab.com/releases/2018/06/22/gitlab-11-0-released/#support-for-dsa-ssh-keys)). +- ECDSA SSH keys are allowed. +- ED25519 SSH keys are allowed. + <!-- ## Troubleshooting Include any troubleshooting steps that you can foresee. If you know beforehand what issues diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md index c00e5bff383..4e72033fd77 100644 --- a/doc/security/token_overview.md +++ b/doc/security/token_overview.md @@ -71,7 +71,7 @@ You can use the runner registration token to add runners that execute jobs in a After registration, the runner receives an authentication token, which it uses to authenticate with GitLab when picking up jobs from the job queue. The authentication token is stored locally in the runner's [`config.toml`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html) file. -After authentication with GitLab, the runner receives a [job token](../api/index.md#gitlab-cicd-job-token), which it uses to execute the job. +After authentication with GitLab, the runner receives a [job token](../ci/jobs/ci_job_token.md), which it uses to execute the job. In case of Docker Machine/Kubernetes/VirtualBox/Parallels/SSH executors, the execution environment has no access to the runner authentication token, because it stays on the runner machine. They have access to the job token only, which is needed to execute the job. @@ -79,7 +79,7 @@ Malicious access to a runner's file system may expose the `config.toml` file and ## CI/CD job tokens -The [CI/CD](../api/index.md#gitlab-cicd-job-token) job token +The [CI/CD](../ci/jobs/ci_job_token.md) job token is a short lived token only valid for the duration of a job. It gives a CI/CD job access to a limited amount of API endpoints. API authentication uses the job token, by using the authorization of the user @@ -105,7 +105,7 @@ This table shows available scopes per token. Scopes can be limited further on to 1. Limited to the one project. 1. Runner registration and authentication token don't provide direct access to repositories, but can be used to register and authenticate a new runner that may execute jobs which do have access to the repository -1. Limited to certain [endpoints](../api/index.md#gitlab-cicd-job-token). +1. Limited to certain [endpoints](../ci/jobs/ci_job_token.md). ## Security considerations diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md index a009fa9964d..a5b01a1b27d 100644 --- a/doc/security/two_factor_authentication.md +++ b/doc/security/two_factor_authentication.md @@ -5,17 +5,15 @@ group: Access info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# Enforce Two-factor Authentication (2FA) +# Enforce two-factor authentication **(FREE SELF)** -Two-factor Authentication (2FA) provides an additional level of security to your -users' GitLab account. After being enabled, in addition to supplying their -username and password to sign in, they are prompted for a code generated by an -application on their phone. +Two-factor authentication (2FA) provides an additional level of security to your +users' GitLab account. When enabled, users are prompted for a code generated by an application in +addition to supplying their username and password to sign in. -You can read more about it here: -[Two-factor Authentication (2FA)](../user/profile/account/two_factor_authentication.md) +Read more about [two-factor authentication (2FA)](../user/profile/account/two_factor_authentication.md) -## Enforcing 2FA for all users +## Enforce 2FA for all users Users on GitLab can enable it without any administrator's intervention. If you want to enforce everyone to set up 2FA, you can choose from two different ways: @@ -28,18 +26,27 @@ cannot leave the 2FA configuration area at `/-/profile/two_factor_auth`. To enable 2FA for all users: -1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the top bar, select **Menu > Admin**. 1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`). 1. Expand the **Sign-in restrictions** section, where you can configure both. If you want 2FA enforcement to take effect during the next sign-in attempt, change the grace period to `0`. -## Enforcing 2FA for all users in a group +## Disable 2FA enforcement through rails console + +Using the [rails console](../administration/operations/rails_console.md), enforcing 2FA for +all user can be disabled. Connect to the rails console and run: + +```ruby +Gitlab::CurrentSettings.update!('require_two_factor_authentication': false) +``` + +## Enforce 2FA for all users in a group **(FREE)** > [Introduced in](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups. -If you want to enforce 2FA only for certain groups: +To enforce 2FA only for certain groups: 1. Go to the group's **Settings > General** page. 1. Expand the **Permissions, LFS, 2FA** section. @@ -47,11 +54,11 @@ If you want to enforce 2FA only for certain groups: You can also specify a grace period in the **Time before enforced** option. -To change this setting, you need to be administrator or owner of the group. +To change this setting, you must be an administrator or owner of the group. If you want to enforce 2FA only for certain groups, you can enable it in the group settings and specify a grace period as above. To change this setting you -need to be administrator or owner of the group. +must be administrator or owner of the group. The following are important notes about 2FA: @@ -74,13 +81,13 @@ The following are important notes about 2FA: This action causes all subgroups with 2FA requirements to stop requiring that from their members. -## Disabling 2FA for everyone +## Disable 2FA for everyone WARNING: -Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforcing-2fa-for-all-users) -or [enforce 2FA for all users in a group](#enforcing-2fa-for-all-users-in-a-group) -settings. In addition to the steps in this section, you must disable any enforced 2FA -settings so users aren't asked to set up 2FA again, the next time the user signs in to GitLab. +Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforce-2fa-for-all-users) +or [enforce 2FA for all users in a group](#enforce-2fa-for-all-users-in-a-group) +settings. You must also disable any enforced 2FA settings so users aren't asked to set up 2FA again +when they next sign in to GitLab. There may be some special situations where you want to disable 2FA for everyone even when forced 2FA is disabled. There is a Rake task for that: @@ -97,26 +104,26 @@ WARNING: This is a permanent and irreversible action. Users have to reactivate 2FA from scratch if they want to use it again. -## Two-factor Authentication (2FA) for Git over SSH operations **(PREMIUM)** +## 2FA for Git over SSH operations **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7. > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/299088) from GitLab Free to GitLab Premium in 13.9. > - It's [deployed behind a feature flag](../user/feature_flags.md), disabled by default. > - It's disabled on GitLab.com. > - It's not recommended for production use. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-two-factor-authentication-2fa-for-git-operations). +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-2fa-for-git-operations). WARNING: This feature might not be available to you. Check the **version history** note above for details. -Two-factor authentication can be enforced for Git over SSH operations. The OTP +Two-factor authentication can be enforced for Git over SSH operations. The one-time password (OTP) verification can be done via a GitLab Shell command: ```shell ssh git@<hostname> 2fa_verify ``` -Once the OTP is verified, Git over SSH operations can be used for a session duration of +After the OTP is verified, Git over SSH operations can be used for a session duration of 15 minutes (default) with the associated SSH key. ### Security limitation @@ -126,9 +133,9 @@ Once the OTP is verified, Git over SSH operations can be used for a session dura Once an OTP is verified, anyone can run Git over SSH with that private SSH key for the configured [session duration](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled). -### Enable or disable Two-factor Authentication (2FA) for Git operations +### Enable or disable 2FA for Git operations -Two-factor Authentication (2FA) for Git operations is under development and not +2FA for Git operations is under development and not ready for production use. It is deployed behind a feature flag that is **disabled by default**. [GitLab administrators with access to the GitLab Rails console](../administration/feature_flags.md) can enable it. @@ -147,7 +154,7 @@ Feature.disable(:two_factor_for_cli) The feature flag affects these features: -- [Two-factor Authentication (2FA) for Git over SSH operations](#two-factor-authentication-2fa-for-git-over-ssh-operations). +- [Two-factor Authentication (2FA) for Git over SSH operations](#2fa-for-git-over-ssh-operations). - [Customize session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled). <!-- ## Troubleshooting diff --git a/doc/security/user_email_confirmation.md b/doc/security/user_email_confirmation.md index 1b39937acbe..09e1e09b676 100644 --- a/doc/security/user_email_confirmation.md +++ b/doc/security/user_email_confirmation.md @@ -11,7 +11,7 @@ GitLab can be configured to require confirmation of a user's email address when the user signs up. When this setting is enabled, the user is unable to sign in until they confirm their email address. -1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the top bar, select **Menu > Admin**. 1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`). 1. Expand the **Sign-up restrictions** section and look for the **Send confirmation email on sign-up** option. diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md index b0535d0bcaf..c0e5d0695cc 100644 --- a/doc/security/webhooks.md +++ b/doc/security/webhooks.md @@ -46,8 +46,8 @@ to `127.0.0.1`, `::1` and `0.0.0.0`, as well as IPv4 `10.0.0.0/8`, `172.16.0.0/1 This behavior can be overridden: -1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Network**. +1. On the top bar, select **Menu > Admin**. +1. On the left sidebar, select **Settings > Network**. 1. Expand the **Outbound requests** section:  1. Select **Allow requests to the local network from web hooks and services**. @@ -65,8 +65,8 @@ You can allow certain domains and IP addresses to be accessible to both *system and *webhooks* even when local requests are not allowed by adding them to the allowlist: -1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings > Network** (`/admin/application_settings/network`) +1. On the top bar, select **Menu > Admin**. +1. On the left sidebar, select **Settings > Network** (`/admin/application_settings/network`) and expand **Outbound requests**:  |