diff options
Diffstat (limited to 'doc/security')
| -rw-r--r-- | doc/security/hardening_application_recommendations.md | 22 | ||||
| -rw-r--r-- | doc/security/hardening_cicd_recommendations.md | 20 | ||||
| -rw-r--r-- | doc/security/hardening_general_concepts.md | 5 | ||||
| -rw-r--r-- | doc/security/index.md | 3 | ||||
| -rw-r--r-- | doc/security/token_overview.md | 3 | ||||
| -rw-r--r-- | doc/security/two_factor_authentication.md | 15 |
6 files changed, 42 insertions, 26 deletions
diff --git a/doc/security/hardening_application_recommendations.md b/doc/security/hardening_application_recommendations.md index 857e322191e..4ff1e94deb4 100644 --- a/doc/security/hardening_application_recommendations.md +++ b/doc/security/hardening_application_recommendations.md @@ -108,7 +108,7 @@ If GitLab is in FIPS mode, use the following: - If using `RSA`, set it to **Must be at least 2048 bits**. - Set all other key types to **Are forbidden**. - If you are setting up an instance for a new group of users, define your user SSH -key policy with the maximum bits settings for added security. + key policy with the maximum bits settings for added security. In a hardened environment RSS feeds are typically not required, and in **Feed token**, select the **Disabled feed token** checkbox. @@ -192,14 +192,14 @@ process or authenticated user. The main focus for hardening is **Usage statistics**: - You should make sure **Enable version check** is selected. This checks to see if you -are running the latest version of GitLab, and as new versions with new features and -security patches come out frequently, this helps you stay up to date. + are running the latest version of GitLab, and as new versions with new features and + security patches come out frequently, this helps you stay up to date. - If your environment is isolated or one where your organizational requirements -restrict data gathering and statistics reporting to a software vendor, you may have -to disable the **Enable service ping** feature. For more information on what data is collected to -help you make an informed decision, see -[service ping](../development/internal_analytics/service_ping/index.md). + restrict data gathering and statistics reporting to a software vendor, you may have + to disable the **Enable service ping** feature. For more information on what data is collected to + help you make an informed decision, see + [service ping](../development/internal_analytics/service_ping/index.md). ## Network @@ -215,12 +215,12 @@ and user needs, which may require disabling and adjusting rate limits or enablin accesses. Here are a few notables to keep in mind: - In **Outbound requests**, if you need to open up access to a limited -number of systems, you can limit access to just those systems by specifying -IP address or hostname. Also in this section, make sure you've selected -**Enforce DNS rebinding attack protection** if you're allowing any access at all. + number of systems, you can limit access to just those systems by specifying + IP address or hostname. Also in this section, make sure you've selected + **Enforce DNS rebinding attack protection** if you're allowing any access at all. - Under **Notes rate limit** and **Users API rate limit** you can exclude specific users -from those limits if needed. + from those limits if needed. <!-- ## Troubleshooting diff --git a/doc/security/hardening_cicd_recommendations.md b/doc/security/hardening_cicd_recommendations.md index 4d0a85c362d..72f3bc8e7b8 100644 --- a/doc/security/hardening_cicd_recommendations.md +++ b/doc/security/hardening_cicd_recommendations.md @@ -22,18 +22,18 @@ individual scenarios themselves are numerous, we have summarized some basic information to help harden the CI/CD process. - **Secrets Management**. Passwords, tokens, keys, and other secrets that require any -level of protection should never be stored in plaintext. Some type of encrypted -container technology should be used, such as GCP Secret Manager, AWS KMS, or -HashiCorp Vault. For self-managed and standalone instances, HashiCorp Vault is -recommended, and many GitLab features can take advantage of Vault and are well -documented in the main [Documentation](../index.md). For detailed CI/CD examples, see [using external secrets in CI](../ci/secrets/index.md). + level of protection should never be stored in plaintext. Some type of encrypted + container technology should be used, such as GCP Secret Manager, AWS KMS, or + HashiCorp Vault. For self-managed and standalone instances, HashiCorp Vault is + recommended, and many GitLab features can take advantage of Vault and are well + documented in the main [Documentation](../index.md). For detailed CI/CD examples, see [using external secrets in CI](../ci/secrets/index.md). - **External Communications**. If your CI/CD process requires connectivity to other -hosts, ensure that these communication channels are encrypted. You should use TLS 1.2 or 1.3, and where possible implement mutual TLS. + hosts, ensure that these communication channels are encrypted. You should use TLS 1.2 or 1.3, and where possible implement mutual TLS. - **Logging**. Logging can be very important for auditing and troubleshooting, so it -is important that you enable any logging features to ensure you are getting -the information in logs you need. Make sure through periodic testing that -plaintext secrets or other sensitive information is not inadvertently added to log -files. + is important that you enable any logging features to ensure you are getting + the information in logs you need. Make sure through periodic testing that + plaintext secrets or other sensitive information is not inadvertently added to log + files. ## Specific Recommendations diff --git a/doc/security/hardening_general_concepts.md b/doc/security/hardening_general_concepts.md index 0ba8822dc5f..cb0dcb4eba7 100644 --- a/doc/security/hardening_general_concepts.md +++ b/doc/security/hardening_general_concepts.md @@ -19,10 +19,9 @@ just one. A quick example is account security: - Use a long, complex, and unique password for the account. - Implement a second factor to the authentication process for added security. - Use a hardware token as a second factor. -- Lock out an account (for at least a fixed amount of time) for failed authentication -attempts. +- Lock out an account (for at least a fixed amount of time) for failed authentication attempts. - An account that is unused for a specific time frame should be disabled, enforce this -with either automation or regular audits. + with either automation or regular audits. Instead of using only one or two items on the list, use as many as possible. This philosophy can apply to other areas besides account security - it should be applied to diff --git a/doc/security/index.md b/doc/security/index.md index 8fd55fd08ff..ffc436e4286 100644 --- a/doc/security/index.md +++ b/doc/security/index.md @@ -1,6 +1,7 @@ --- stage: Govern group: Authentication +description: SSH key limits, 2FA, tokens, hardening. info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- @@ -27,6 +28,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w - [Maximum decompressed file size for imported archives](../administration/settings/import_and_export_settings.md#maximum-decompressed-file-size-for-imported-archives) - [Responding to security incidents](responding_to_security_incidents.md) -To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../administration/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md). For more detailed information, refer to [Hardening](hardening.md). +To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../administration/settings/sign_up_restrictions.md) and [Authentication options](../administration/auth/index.md). For more detailed information, refer to [Hardening](hardening.md). Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance. diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md index 4555459e7c5..9cd445ed47b 100644 --- a/doc/security/token_overview.md +++ b/doc/security/token_overview.md @@ -238,13 +238,14 @@ The following tables show the prefixes for each type of token where applicable. | Deploy key | Not applicable. | | Runner registration token | Not applicable. | | Runner authentication token | `glrt-` | -| Job token | Not applicable. | +| CI/CD Job token | `glcbt-` ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/426137) in GitLab 16.8 behind a feature flag named `prefix_ci_build_tokens`. Disabled by default.) | | Trigger token | `glptt-` | | Legacy runner registration token | GR1348941 | | Feed token | `glft-` | | Incoming mail token | `glimt-` | | GitLab Agent for Kubernetes token | `glagent-` | | GitLab session cookies | `_gitlab_session=` | +| SCIM Tokens | `glsoat-` ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/435096) in GitLab 16.8 behind a feature flag named `prefix_scim_tokens`. Disabled by default.) | ### External system tokens diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md index c7d6796a212..80b6988b1b1 100644 --- a/doc/security/two_factor_authentication.md +++ b/doc/security/two_factor_authentication.md @@ -49,6 +49,21 @@ Use the [application settings API](../api/settings.md) to modify the following s For more information, see the [list of settings that can be accessed through API calls](../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls). +## Enforce 2FA for Administrator users **(FREE SELF)** + +Administrators can enforce 2FA for administrator users in a self-managed instance. + +1. On the left sidebar, at the bottom, select **Admin Area**. +1. On the left sidebar, select **Settings > General**. +1. Expand the **Sign-in restrictions** section: + - Select **Require administrators to enable 2FA**. + - In **Two-factor grace period**, enter a number of hours. If you want to + enforce 2FA on the next sign-in attempt, enter `0`. +1. Select **Save changes**. + +NOTE: +If you are using an external provider to sign in into GitLab, this setting will **not** enforce 2FA for users. 2FA should be enabled on that external provider. + ## Enforce 2FA for all users in a group **(FREE ALL)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) in GitLab 12.0, 2FA settings for a group are also applied to subgroups. |