diff --git a/.gitlab/ci/test-on-omnibus-nightly/main.gitlab-ci.yml b/.gitlab/ci/test-on-omnibus-nightly/main.gitlab-ci.yml index 658d2052424..2c076fe2b37 100644 --- a/.gitlab/ci/test-on-omnibus-nightly/main.gitlab-ci.yml +++ b/.gitlab/ci/test-on-omnibus-nightly/main.gitlab-ci.yml @@ -179,17 +179,6 @@ gitlab-pages: variables: QA_SCENARIO: Test::Integration::GitlabPages -# ========== git sha256 enabled =========== -git-sha256-repositories: - extends: - - .parallel - - .qa - - .with-ignored-runtime-data - variables: - QA_SCENARIO: Test::Instance::Image - QA_USE_SHA256_REPOSITORY_OBJECT_STORAGE: true - GITLAB_QA_OPTS: "--enable-feature support_sha256_repositories" - # ========== Update From Previous with AI components =========== update-minor-ee-ai-components: extends: diff --git a/GITALY_SERVER_VERSION b/GITALY_SERVER_VERSION index 7db8b39a4ec..569ecff8034 100644 --- a/GITALY_SERVER_VERSION +++ b/GITALY_SERVER_VERSION @@ -1 +1 @@ -4064e55eea5f1bb415cb57e8aa23630b14d7e387 +0173c7eadd49ca64bdd04aa2cc2b47607b09988b diff --git a/GITLAB_KAS_VERSION b/GITLAB_KAS_VERSION index e2683dee923..80c4807200a 100644 --- a/GITLAB_KAS_VERSION +++ b/GITLAB_KAS_VERSION @@ -1 +1 @@ -8a9909381cf05e2d68b28d123337ba8c7bc5da30 +bb5dd9c7ced8de9cf7f5405a34836e6fb7f8e8a4 diff --git a/app/assets/javascripts/blob/components/blob_header_filepath.vue b/app/assets/javascripts/blob/components/blob_header_filepath.vue index c8dfdc522cb..1e8b7c55725 100644 --- a/app/assets/javascripts/blob/components/blob_header_filepath.vue +++ b/app/assets/javascripts/blob/components/blob_header_filepath.vue @@ -64,7 +64,7 @@ export default { {{ fileName }} - {{ blobSize }} + {{ blobSize }} {{ __('LFS') }} diff --git a/app/assets/stylesheets/framework/common.scss b/app/assets/stylesheets/framework/common.scss index 7493fded3e9..f4a700e01d1 100644 --- a/app/assets/stylesheets/framework/common.scss +++ b/app/assets/stylesheets/framework/common.scss @@ -95,7 +95,7 @@ .hint { font-style: italic; - color: $gray-200; + @apply gl-text-disabled; } .light { @apply gl-text-default; } @@ -182,7 +182,7 @@ table { } p.time { - color: $gray-200; + @apply gl-text-disabled; font-size: 90%; margin: 30px 3px 3px 2px; } diff --git a/app/assets/stylesheets/framework/files.scss b/app/assets/stylesheets/framework/files.scss index ded568a4bc1..69b06c04e8b 100644 --- a/app/assets/stylesheets/framework/files.scss +++ b/app/assets/stylesheets/framework/files.scss @@ -202,7 +202,7 @@ span.idiff { flex-wrap: wrap; align-items: center; justify-content: space-between; - @apply gl-bg-subtle gl-border-b gl-border-b-section; + @apply gl-bg-subtle gl-border-b; padding: $gl-padding-8 $gl-padding; margin: 0; min-height: px-to-rem($file-header-height); diff --git a/app/assets/stylesheets/framework/mixins.scss b/app/assets/stylesheets/framework/mixins.scss index 0a46a2527f0..acfaa2ddeb2 100644 --- a/app/assets/stylesheets/framework/mixins.scss +++ b/app/assets/stylesheets/framework/mixins.scss @@ -192,7 +192,7 @@ */ @mixin build-log($background: $black) { background: $background; - color: $gray-200; + @apply gl-text-disabled; white-space: pre; overflow-x: auto; font-size: 12px; diff --git a/app/assets/stylesheets/page_bundles/editor.scss b/app/assets/stylesheets/page_bundles/editor.scss index d20cb906b21..938ea225414 100644 --- a/app/assets/stylesheets/page_bundles/editor.scss +++ b/app/assets/stylesheets/page_bundles/editor.scss @@ -21,7 +21,7 @@ } .editor-ref { - background: var(--gray-10, $gray-10); + @apply gl-bg-subtle; padding-right: $gl-padding; border-right: 1px solid var(--gl-border-color-default); display: block; diff --git a/app/assets/stylesheets/page_bundles/environments.scss b/app/assets/stylesheets/page_bundles/environments.scss index f81a018b6e8..c246d971509 100644 --- a/app/assets/stylesheets/page_bundles/environments.scss +++ b/app/assets/stylesheets/page_bundles/environments.scss @@ -156,7 +156,7 @@ i { cursor: pointer; - color: var(--gray-200, $gray-200); + @apply gl-text-disabled; padding-right: 10px; } } diff --git a/app/assets/stylesheets/page_bundles/ide.scss b/app/assets/stylesheets/page_bundles/ide.scss index edd4e7bd5f1..0ed6d5d46c4 100644 --- a/app/assets/stylesheets/page_bundles/ide.scss +++ b/app/assets/stylesheets/page_bundles/ide.scss @@ -1038,7 +1038,7 @@ $ide-commit-header-height: 48px; .terminal-wrapper { background: $black; - color: $gray-200; + @apply gl-text-disabled; overflow: hidden; } diff --git a/app/assets/stylesheets/page_bundles/users.scss b/app/assets/stylesheets/page_bundles/users.scss index 537fee9f505..ac9133cfda1 100644 --- a/app/assets/stylesheets/page_bundles/users.scss +++ b/app/assets/stylesheets/page_bundles/users.scss @@ -2,7 +2,7 @@ .user-search-btn { top: 1px; - color: $gray-200; + @apply gl-text-disabled; background: transparent; border: 0; outline: 0; diff --git a/app/graphql/mutations/todos/base_many.rb b/app/graphql/mutations/todos/base_many.rb index c2d5ecf22f5..8d424a5823d 100644 --- a/app/graphql/mutations/todos/base_many.rb +++ b/app/graphql/mutations/todos/base_many.rb @@ -17,7 +17,7 @@ module Mutations description: 'Updated to-do items.' def resolve(ids:) - check_update_amount_limit!(ids) + check_update_limit!(amount: ids.size) todos = authorized_find_all_pending_by_current_user(model_ids_of(ids)) updated_ids = process_todos(todos) @@ -47,8 +47,8 @@ module Mutations raise Gitlab::Graphql::Errors::ArgumentError, 'Too many to-do items requested.' end - def check_update_amount_limit!(ids) - raise_too_many_todos_requested_error if ids.size > MAX_UPDATE_AMOUNT + def check_update_limit!(amount:) + raise_too_many_todos_requested_error if amount > MAX_UPDATE_AMOUNT end def errors_on_objects(todos) diff --git a/app/views/projects/blob/_header_content.html.haml b/app/views/projects/blob/_header_content.html.haml index 5c810ff67ef..46cd2e2d536 100644 --- a/app/views/projects/blob/_header_content.html.haml +++ b/app/views/projects/blob/_header_content.html.haml @@ -3,12 +3,12 @@ .js-table-contents = blob_icon blob.mode, blob.name - %strong.file-title-name.gl-break-all{ data: { testid: 'file-name-content' } } + %strong.file-title-name.gl-text-strong.gl-break-all{ data: { testid: 'file-name-content' } } = blob.name = copy_file_path_button(blob.path) - %small.mr-1 + %small.gl-mr-1.gl-text-subtle - if blob.symlink? = _('Symbolic link') << ' ·' = number_to_human_size(blob.raw_size) diff --git a/app/views/projects/diffs/_file_header.html.haml b/app/views/projects/diffs/_file_header.html.haml index e8221926904..0f58c35b5a0 100644 --- a/app/views/projects/diffs/_file_header.html.haml +++ b/app/views/projects/diffs/_file_header.html.haml @@ -7,7 +7,7 @@ %span = sprite_icon('folder-git', file_icon: true) - %strong.file-title-name + %strong.file-title-name.gl-text-strong = submodule_link(diff_file.blob, diff_file.content_sha, diff_file.repository) = copy_file_path_button(diff_file.blob.path) @@ -17,13 +17,13 @@ - if diff_file.renamed_file? - old_path, new_path = mark_inline_diffs(diff_file.old_path, diff_file.new_path) - %strong.file-title-name.has-tooltip.gl-break-all{ data: { title: diff_file.old_path, container: 'body' } } + %strong.file-title-name.gl-text-strong.has-tooltip.gl-break-all{ data: { title: diff_file.old_path, container: 'body' } } = old_path → - %strong.file-title-name.has-tooltip.gl-break-all{ data: { title: diff_file.new_path, container: 'body' } } + %strong.file-title-name.gl-text-strong.has-tooltip.gl-break-all{ data: { title: diff_file.new_path, container: 'body' } } = new_path - else - %strong.file-title-name.has-tooltip.gl-break-all{ data: { title: diff_file.file_path, container: 'body', testid: 'file-name-content' } } + %strong.file-title-name.gl-text-strong.has-tooltip.gl-break-all{ data: { title: diff_file.file_path, container: 'body', testid: 'file-name-content' } } = diff_file.file_path - if diff_file.deleted_file? @@ -32,7 +32,7 @@ = copy_file_path_button(diff_file.file_path) - if diff_file.mode_changed? - %small.gl-mr-2 + %small.gl-mr-2.gl-text-subtle #{diff_file.a_mode} → #{diff_file.b_mode} - if diff_file.stored_externally? && diff_file.external_storage == :lfs diff --git a/app/views/search/results/_blob_data.html.haml b/app/views/search/results/_blob_data.html.haml index c0d95151605..d377c9fe3ec 100644 --- a/app/views/search/results/_blob_data.html.haml +++ b/app/views/search/results/_blob_data.html.haml @@ -3,7 +3,7 @@ .js-file-title.file-title{ data: { testid: 'file-title-content' } } = link_to blob_link, data: { event_tracking: 'click_search_result', event_label: @scope, event_value: position } do = sprite_icon('document') - %strong + %strong.gl-text-strong = search_blob_title(project, path) = copy_file_path_button(path) - if blob.data diff --git a/app/views/shared/snippets/_embed.html.haml b/app/views/shared/snippets/_embed.html.haml index 713bfa992eb..8dbf8e141a7 100644 --- a/app/views/shared/snippets/_embed.html.haml +++ b/app/views/shared/snippets/_embed.html.haml @@ -3,11 +3,11 @@ .file-header-content = external_snippet_icon('doc-text') - %strong.file-title-name + %strong.file-title-name.gl-text-strong %a.gitlab-embedded-snippets-title{ href: url_for(only_path: false, overwrite_params: nil), target: '_blank', rel: 'noopener noreferrer' } = blob.name - %small + %small.gl-text-subtle = number_to_human_size(blob.size) %a.gitlab-logo-wrapper{ href: url_for(only_path: false, overwrite_params: nil), title: 'View on GitLab', target: '_blank', rel: 'noopener noreferrer' } %img.gitlab-logo{ src: image_url('ext_snippet_icons/logo.svg'), alt: "GitLab logo" } diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md index be6511666da..aee3983c204 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -39323,6 +39323,7 @@ Conversation type of the thread. | Value | Description | | ----- | ----------- | | `DUO_CHAT` | duo_chat thread. | +| `DUO_CODE_REVIEW` | duo_code_review thread. | ### `AiFeatureProviders` diff --git a/doc/api/packages/conan.md b/doc/api/packages/conan.md index c5240e768d9..8dc81ab9361 100644 --- a/doc/api/packages/conan.md +++ b/doc/api/packages/conan.md @@ -24,7 +24,7 @@ These endpoints do not adhere to the standard API authentication methods. See each route for details on how credentials are expected to be passed. Undocumented authentication methods might be removed in the future. NOTE: -The Conan registry is not FIPS compliant and is disabled when [FIPS mode](../../development/fips_compliance.md) is enabled. +The Conan registry is not FIPS compliant and is disabled when [FIPS mode](../../development/fips_gitlab.md) is enabled. These endpoints will all return 404 Not Found. ## Route prefix diff --git a/doc/api/packages/pypi.md b/doc/api/packages/pypi.md index 98f3c46714f..3155eeac1d4 100644 --- a/doc/api/packages/pypi.md +++ b/doc/api/packages/pypi.md @@ -26,7 +26,7 @@ for details on which headers and token types are supported. Undocumented authent NOTE: [Twine 3.4.2](https://twine.readthedocs.io/en/stable/changelog.html?highlight=FIPS#id28) or greater -is recommended when [FIPS mode](../../development/fips_compliance.md) is enabled. +is recommended when [FIPS mode](../../development/fips_gitlab.md) is enabled. ## Download a package file from a group diff --git a/doc/ci/runners/hosted_runners/macos.md b/doc/ci/runners/hosted_runners/macos.md index 9c1af9f9fd3..6212342c2f8 100644 --- a/doc/ci/runners/hosted_runners/macos.md +++ b/doc/ci/runners/hosted_runners/macos.md @@ -24,7 +24,7 @@ GitLab offers the following machine type for hosted runners on macOS. To build f | Runner Tag | vCPUS | Memory | Storage | | ------------------------ | ----- | ------ | ------- | -| `saas-macos-medium-m1` | 4 | 8 GB | 25 GB | +| `saas-macos-medium-m1` | 4 | 8 GB | 50 GB | | `saas-macos-large-m2pro` | 6 | 16 GB | 50 GB | ## Supported macOS images diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md index bd8a1e4176b..600a74465cd 100644 --- a/doc/ci/variables/predefined_variables.md +++ b/doc/ci/variables/predefined_variables.md @@ -77,7 +77,7 @@ Predefined variables become available at three different phases of pipeline exec | `CI_ENVIRONMENT_URL` | Pipeline | The URL of the environment for this job. Available if [`environment:url`](../yaml/index.md#environmenturl) is set. | | `CI_ENVIRONMENT_ACTION` | Pipeline | The action annotation specified for this job's environment. Available if [`environment:action`](../yaml/index.md#environmentaction) is set. Can be `start`, `prepare`, or `stop`. | | `CI_ENVIRONMENT_TIER` | Pipeline | The [deployment tier of the environment](../environments/index.md#deployment-tier-of-environments) for this job. | -| `CI_GITLAB_FIPS_MODE` | Pre-pipeline | Only available if [FIPS mode](../../development/fips_compliance.md) is enabled in the GitLab instance. `true` when available. | +| `CI_GITLAB_FIPS_MODE` | Pre-pipeline | Only available if [FIPS mode](../../development/fips_gitlab.md) is enabled in the GitLab instance. `true` when available. | | `CI_HAS_OPEN_REQUIREMENTS` | Pipeline | Only available if the pipeline's project has an open [requirement](../../user/project/requirements/index.md). `true` when available. | | `CI_JOB_ID` | Job-only | The internal ID of the job, unique across all jobs in the GitLab instance. | | `CI_JOB_IMAGE` | Pipeline | The name of the Docker image running the job. | diff --git a/doc/development/feature_development.md b/doc/development/feature_development.md index e6adae3a98a..9a7163f52be 100644 --- a/doc/development/feature_development.md +++ b/doc/development/feature_development.md @@ -29,7 +29,7 @@ Consult these topics for information on contributing to specific GitLab features - [Permissions](permissions.md) - [Code comments](code_comments.md) - [Windows Development on GCP](windows.md) -- [FIPS compliance](fips_compliance.md) +- [FIPS 140-2 and 140-3](fips_gitlab.md) - [`Gemfile` guidelines](gemfile.md) - [Ruby upgrade guidelines](ruby_upgrade.md) diff --git a/doc/development/fips_compliance.md b/doc/development/fips_compliance.md index b6c0b96058a..0e0c0efb98b 100644 --- a/doc/development/fips_compliance.md +++ b/doc/development/fips_compliance.md @@ -1,513 +1,13 @@ --- -stage: Create -group: Source Code -info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review. +redirect_to: 'fips_gitlab.md' +remove_date: '2025-04-29' --- -# FIPS compliance + -FIPS is short for "Federal Information Processing Standard", a document which -defines certain security practices for a "cryptographic module" (CM). It aims -to ensure a certain security floor is met by vendors selling products to U.S. -Federal institutions. +This document was moved to [another location](fips_gitlab.md). -WARNING: -You can build a FIPS-compliant instance of GitLab, but [not all features are included](#unsupported-features-in-fips-mode). -A FIPS-compliant instance must be configured following the [FIPS install instructions](#install-gitlab-with-fips-compliance) -exactly. - -The two current FIPS standards: [140-2](https://en.wikipedia.org/wiki/FIPS_140-2) -and [140-3](https://en.wikipedia.org/wiki/FIPS_140-3). At GitLab we usually -mean FIPS 140-2. - -## Current status - -GitLab has completed FIPS 140-2 Compliance for the build specified in this documentation. You can find our FIPS 140-2 Attestation in our [customer assurance package](https://trust.gitlab.com/), specifically the community package. - -## FIPS compliance at GitLab - -To be compliant, all components (GitLab itself, Gitaly, etc) must be compliant, -along with the communication between those components, and any storage used by -them. Where functionality cannot be brought into compliance, it must be disabled -when FIPS mode is enabled. FIPS-compliant cryptography means that a cryptographic -operation leverages a FIPS-validated module. - -### Leveraged Cryptographic modules - -The following list is for reference purposes only and is not dynamically updated. The latest CMVP certificates for the modules below will apply. - -| Cryptographic module name | CMVP number | Instance type | Software component used | -|----------------------------------------------------------|-------------------------------------------------------------------------------------------------|---------------|-------------------------| -| Ubuntu 20.04 AWS Kernel Crypto API Cryptographic Module | [4366](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4366) | EC2 (Omnibus) | Linux kernel | -| Ubuntu 20.04 OpenSSL Cryptographic Module | [4292](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4292) | EC2 (Omnibus) | Gitaly, Rails (Puma/Sidekiq) | -| Ubuntu 20.04 Libgcrypt Cryptographic Module | [3902](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3902) | EC2 (Omnibus) | `gpg`, `sshd` | -| Amazon Linux 2 Kernel Crypto API Cryptographic Module | [4593](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4593) | EKS nodes | Linux kernel | -| Amazon Linux 2 OpenSSL Cryptographic Module | [4548](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4548) | EKS nodes | EKS | -| Red Hat Enterprise Linux 8 OpenSSL Cryptographic Module | [4642](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4642) | GitLab Helm chart | UBI containers: Workhorse, Pages, container registry, Rails (Puma/Sidekiq), Security Analyzers, `gitlab-sshd` | -| Red Hat Enterprise Linux 8 Libgcrypt Cryptographic Module | [4438](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4438) | GitLab Helm chart | UBI containers: GitLab Shell, `gpg` | - -### Supported Operating Systems - -The supported hybrid platforms are: - -- Omnibus GitLab: Ubuntu 20.04 LTS -- Cloud Native GitLab: Amazon Linux 2 (EKS) - -### Unsupported features in FIPS mode - -Some GitLab features may not work when FIPS mode is enabled. The following features -are known to not work in FIPS mode. However, there may be additional features not -listed here that also do not work properly in FIPS mode: - -- [Container Scanning](../user/application_security/container_scanning/index.md) support for scanning images in repositories that require authentication. -- [Code Quality](../ci/testing/code_quality.md) does not support operating in FIPS-compliant mode. -- [Dependency scanning](../user/application_security/dependency_scanning/index.md) support for Gradle. -- [Solutions for vulnerabilities](../user/application_security/vulnerabilities/index.md#resolve-a-vulnerability) - for yarn projects. -- [Static Application Security Testing (SAST)](../user/application_security/sast/index.md) - supports a reduced set of [analyzers](../user/application_security/sast/index.md#fips-enabled-images) - when operating in FIPS-compliant mode. -- [Operational Container Scanning](../user/clusters/agent/vulnerabilities.md). - -Additionally, these package repositories are disabled in FIPS mode: - -- [Conan package repository](../user/packages/conan_repository/index.md). -- [Debian package repository](../user/packages/debian_repository/index.md). - -## FIPS compliance vs FIPS validation at GitLab - -GitLab does not fork or modify cryptographic binaries (for example OpenSSL) in its FIPS-compliant -software releases but instead uses existing, FIPS-validated cryptographic software (modules). -GitLab therefore does not need to submit its software through the -[NIST Cryptographic Module Validation Program (CMVP)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/) -independent laboratory testing. -Instead, GitLab must use FIPS-validated software (listed in -[Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)) -that has an active CMVP certificate and ensure it is enabled for all cryptographic operations. - -FIPS-compliant cryptography means that a cryptographic operation uses a FIPS-validated module. -FIPS mode must be enabled on one or both sides of every communication session (that is, client, server, or both). -Enabling FIPS mode on the client ensures that the client uses strong cryptographic algorithms that -are compliant with FIPS 140-3/FIPS 140-2 for encryption, hashing, and signing. -If FIPS mode is not enabled on the client, it must be implemented on the server-side or application -load balancer or proxy server to allow for FIPS-compliant connections to be made. - -## Install GitLab with FIPS compliance - -This guide is specifically for public users or GitLab team members with a requirement -to run a production instance of GitLab that is FIPS compliant. This guide outlines -a hybrid deployment using elements from both Omnibus and our Cloud Native GitLab installations. - -### Prerequisites - -- Amazon Web Services account. Our first target environment is running on AWS, and uses other FIPS Compliant AWS resources. For many AWS resources, you must use a [FIPS specific endpoint](https://aws.amazon.com/compliance/fips/). -- Ability to run Ubuntu 20.04 machines for GitLab. Our first target environment uses the hybrid architecture. -- Advanced Search: GitLab does not provide a packaged Elastic or OpenSearch deployment. You must use a FIPS-compliant service or disable Advanced Search. - -### Set up a FIPS-enabled cluster - -You can use the [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to spin -up a FIPS-enabled cluster for development and testing. As mentioned in the prerequisites, these instructions use Amazon Web Services (AWS) -because that is the first target environment. - -#### Set up your environment - -To get started, your AWS account must subscribe to a FIPS-enabled Amazon -Machine Image (AMI) in the [AWS Marketplace console](https://repost.aws/knowledge-center/launch-ec2-marketplace-subscription). - -This example assumes that the `Ubuntu Pro 20.04 FIPS LTS` AMI by -`Canonical Group Limited` has been added your account. This operating -system is used for virtual machines running in Amazon EC2. - -#### Omnibus - -The simplest way to get a FIPS-enabled GitLab cluster is to use an Omnibus reference architecture. -See the [GET Quick Start Guide](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/docs/environment_quick_start_guide.md) -for more details. The following instructions build on the Quick Start and are also necessary for [Cloud Native Hybrid](#cloud-native-hybrid) installations. - -##### Terraform: Use a FIPS AMI - -GitLab team members can view more information in this internal handbook page on how to use FIPS AMI: -`https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#terraform---use-fips-ami` - -##### Ansible: Specify the FIPS Omnibus builds - -The standard Omnibus GitLab releases build their own OpenSSL library, which is -not FIPS-validated. However, we have nightly builds that create Omnibus packages -that link against the operating system's OpenSSL library. To use this package, -update the `gitlab_edition` and `gitlab_repo_script_url` fields in the Ansible -`vars.yml`. - -GitLab team members can view more information in this internal handbook page on Ansible (AWS): -`https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#ansible-aws` - -#### Cloud Native Hybrid - -A Cloud Native Hybrid install uses both Omnibus and Cloud Native GitLab -(CNG) images. The previous instructions cover the Omnibus part, but two -additional steps are needed to enable FIPS in CNG: - -1. Use a custom Amazon Elastic Kubernetes Service (EKS) AMI. -1. Use GitLab containers built with RedHat's Universal Base Image (UBI). - -##### Build a custom EKS AMI - -Because Amazon does not yet publish a FIPS-enabled AMI, you have to -build one yourself with Packer. - -Amazon publishes the following Git repositories with information about custom EKS AMIs: - -- [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami) -- [Sample EKS custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis/) - -This [GitHub pull request](https://github.com/awslabs/amazon-eks-ami/pull/898) makes -it possible to create an Amazon Linux 2 EKS AMI with FIPS enabled for Kubernetes v1.21. -To build an image: - -1. [Install Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli). -1. Run the following: - - ```shell - git clone https://github.com/awslabs/amazon-eks-ami - cd amazon-eks-ami - git fetch origin pull/898/head:fips-ami - git checkout fips-ami - AWS_DEFAULT_REGION=us-east-1 make 1.21-fips # Be sure to set the region accordingly - ``` - -If you are using a different version of Kubernetes, adjust the `make` -command and `Makefile` accordingly. - -When the AMI build is done, a new AMI should be created with a message -such as the following: - -```plaintext -==> Builds finished. The artifacts of successful builds are: ---> amazon-ebs: AMIs were created: -us-west-2: ami-0a25e760cd00b027e -``` - -In this example, the AMI ID is `ami-0a25e760cd00b027e`, but your value may -be different. - -Building a RHEL-based system with FIPS enabled should be possible, but -there is [an outstanding issue preventing the Packer build from completing](https://github.com/aws-samples/amazon-eks-custom-amis/issues/51). - -Because this builds a custom AMI based on a specific version of an image, you must periodically rebuild the custom AMI to keep current with the latest security patches and upgrades. - -##### Terraform: Use a custom EKS AMI - -GitLab team members can view more information in this internal handbook page on how to use a custom EKS AMI: -`https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#terraform---use-a-custom-eks-ami` - -##### Ansible: Use UBI images - -CNG uses a Helm Chart to manage which container images to deploy. To use UBI-based containers, edit the Ansible `vars.yml` to use custom -Charts variables: - -```yaml -all: - vars: - ... - gitlab_charts_custom_config_file: '/path/to/gitlab-environment-toolkit/ansible/environments/gitlab-10k/inventory/charts.yml' -``` - -Now create `charts.yml` in the location specified above and specify tags with a `-fips` suffix. - -See our [Charts documentation on FIPS](https://docs.gitlab.com/charts/advanced/fips/index.html) for more details, including -an [example values file](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/fips/values.yaml) as a reference. - -You can also use release tags, but the versioning is tricky because each -component may use its own versioning scheme. For example, for GitLab v15.2: - -```yaml -global: - image: - tagSuffix: -fips - certificates: - image: - tag: 20211220-r0 - kubectl: - image: - tag: 1.18.20 - -gitlab: - gitaly: - image: - tag: v15.2.0 - gitlab-exporter: - image: - tag: 11.17.1 - gitlab-shell: - image: - tag: v14.9.0 - gitlab-mailroom: - image: - tag: v15.2.0 - gitlab-pages: - image: - tag: v1.61.0 - migrations: - image: - tag: v15.2.0 - sidekiq: - image: - tag: v15.2.0 - toolbox: - image: - tag: v15.2.0 - webservice: - image: - tag: v15.2.0 - workhorse: - tag: v15.2.0 -``` - -## FIPS Performance Benchmarking - -The Quality Engineering Enablement team assists these efforts by checking if FIPS-enabled environments perform well compared to non-FIPS environments. - -Testing shows an impact in some places, such as Gitaly SSL, but it's not large enough to impact customers. - -You can find more information on FIPS performance benchmarking in the following issue: - -- [Benchmark performance of FIPS reference architecture](https://gitlab.com/gitlab-org/gitlab/-/issues/364051#note_1010450415) - -## Setting up a FIPS-enabled development environment - -The simplest approach is to set up a virtual machine running -[Red Hat Enterprise Linux 8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#switching-the-system-to-fips-mode_using-the-system-wide-cryptographic-policies). - -Red Hat provide free licenses to developers, and permit the CD image to be -downloaded from the [Red Hat developer's portal](https://developers.redhat.com). -Registration is required. - -After the virtual machine is set up, you can follow the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) -installation instructions, including the [advanced instructions for RHEL](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/advanced.md#red-hat-enterprise-linux). -The `asdf` tool is not used for dependency management because it's essential to -use the RedHat-provided Go compiler and other system dependencies. - -### Enable FIPS mode - -After GDK and its dependencies are installed, run this command (as -root) and restart the virtual machine: - -```shell -fips-mode-setup --enable -``` - -You can check whether it's taken effect by running: - -```shell -fips-mode-setup --check -``` - -In this environment, OpenSSL refuses to perform cryptographic operations -forbidden by the FIPS standards. This enables you to reproduce FIPS-related bugs, -and validate fixes. - -You should be able to open a web browser inside the virtual machine and sign in -to the GitLab instance. - -You can disable FIPS mode again by running this command, then restarting the -virtual machine: - -```shell -fips-mode-setup --disable -``` - -#### Detect FIPS enablement in code - -You can query `Gitlab::FIPS` in Ruby code to determine if the instance is FIPS-enabled: - -```ruby -def default_min_key_size(name) - if Gitlab::FIPS.enabled? - Gitlab::SSHPublicKey.supported_sizes(name).select(&:positive?).min || -1 - else - 0 - end -end -``` - -## Omnibus FIPS packages - -GitLab has a dedicated repository -([`gitlab/gitlab-fips`](https://packages.gitlab.com/gitlab/gitlab-fips)) -for builds of the Omnibus GitLab which are built with FIPS compliance. -These GitLab builds are compiled to use the system OpenSSL, instead of -the Omnibus-embedded version of OpenSSL. These packages are built for: - -- RHEL 8 (and compatible) -- AmazonLinux 2 -- Ubuntu - -These are [consumed by the GitLab Environment Toolkit](#install-gitlab-with-fips-compliance) (GET). - -See [the section on how FIPS builds are created](#how-fips-builds-are-created). - -### System Libgcrypt - -Because of a bug, FIPS Linux packages for GitLab 17.6 and earlier did not use the system -[Libgcrypt](https://www.gnupg.org/software/libgcrypt/index.html), but the same Libgcrypt -bundled with regular Linux packages. - -This issue is fixed for all FIPS Linux packages for GitLab 17.7, except for AmazonLinux 2. -The Libgcrypt version of AmazonLinux 2 is not compatible with the -[GPGME](https://gnupg.org/software/gpgme/index.html) and [GnuPG](https://gnupg.org/) -versions shipped with the FIPS Linux packages. - -FIPS Linux packages for AmazonLinux 2 will continue to use the same Libgcrypt bundled with -the regular Linux packages, otherwise we would have to downgrade GPGME and GnuPG. - -If you require full compliance, you must migrate to another operating -system for which FIPS Linux packages are available. - -### Nightly Omnibus FIPS builds - -The Distribution team has created [nightly FIPS Omnibus builds](https://packages.gitlab.com/gitlab/nightly-fips-builds), -which can be used for *testing* purposes. These should never be used for production environments. - -## Runner - -See the [documentation on installing a FIPS-compliant GitLab Runner](https://docs.gitlab.com/runner/install/#fips-compliant-gitlab-runner). - -## Verify FIPS - -The following sections describe ways you can verify if FIPS is enabled. - -### Kernel - -```shell -$ cat /proc/sys/crypto/fips_enabled -1 -``` - -### Ruby (Omnibus images) - -```ruby -$ /opt/gitlab/embedded/bin/irb -irb(main):001:0> require 'openssl'; OpenSSL.fips_mode -=> true -``` - -### Ruby (CNG images) - -```ruby -$ irb -irb(main):001:0> require 'openssl'; OpenSSL.fips_mode -=> true -``` - -### Go - -Google maintains a [`dev.boringcrypto` branch](https://github.com/golang/go/tree/dev.boringcrypto) in the Go compiler -that makes it possible to statically link BoringSSL, a FIPS-validated module forked from OpenSSL. -However, BoringSSL is not intended for public use. - -We use [`golang-fips`](https://github.com/golang-fips/go), [a fork of the `dev.boringcrypto` branch](https://github.com/golang/go/blob/2fb6bf8a4a51f92f98c2ae127eff2b7ac392c08f/README.boringcrypto.md) to build Go programs that -[dynamically link OpenSSL via `dlopen`](https://github.com/golang-fips/go/blob/go1.18.1-1-openssl-fips/src/crypto/internal/boring/boring.go#L47-L65). This has several advantages: - -- Using a FIPS-validated, system OpenSSL is straightforward. -- This is the source code used by the [Red Hat go-toolset package](https://gitlab.com/redhat/centos-stream/rpms/golang#sources). -- Unlike [go-toolset](https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-hat-enterprise-linux#), this fork appears to keep up with the latest Go releases. - -However, [cgo](https://pkg.go.dev/cmd/cgo) must be enabled via `CGO_ENABLED=1` for this to work. There -is a performance hit when calling into C code. - -Projects that are compiled with `golang-fips` on Linux x86 automatically -get built the crypto routines that use OpenSSL. While the `boringcrypto` -build tag is automatically present, no extra build tags are actually -needed. There are [specific build tags](https://github.com/golang-fips/go/blob/go1.18.1-1-openssl-fips/src/crypto/internal/boring/boring.go#L6) -that disable these crypto hooks. - -We can [check whether a given binary is using OpenSSL](https://go.googlesource.com/go/+/dev.boringcrypto/misc/boring/#caveat) via `go tool nm` -and look for symbols named `Cfunc__goboringcrypto` or `crypto/internal/boring/sig.BoringCrypto`. - -For example: - -```console -$ # Find in a Golang-FIPS 1.17 library -$ go tool nm nginx-ingress-controller | grep '_Cfunc__goboringcrypto_|\bcrypto/internal/boring/sig\.BoringCrypto' | tail - 2a0b650 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Final - 2a0b658 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Init - 2a0b660 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Update - 2a0b668 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Final - 2a0b670 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Init - 2a0b678 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Update - 2a0b680 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_sign - 2a0b688 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_verify - 2a0b690 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_error_string_n - 2a0b698 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_get_error -$ # Find in a Golang-FIPS 1.22 library -$ go tool nm tenctl | grep '_Cfunc__goboringcrypto_|\bcrypto/internal/boring/sig\.BoringCrypto' - 4cb840 t crypto/internal/boring/sig.BoringCrypto.abi0 -``` - -In addition, LabKit contains routines to [check whether FIPS is enabled](https://gitlab.com/gitlab-org/labkit/-/tree/master/fips). - -## How FIPS builds are created - -Many GitLab projects (for example: Gitaly, GitLab Pages) have -standardized on using `FIPS_MODE=1 make` to build FIPS binaries locally. - -### Omnibus - -The Omnibus FIPS builds are triggered with the `USE_SYSTEM_SSL` -environment variable set to `true`. When this environment variable is -set, the Omnibus recipes dependencies such as `curl`, NGINX, and libgit2 -will link against the system OpenSSL. OpenSSL will NOT be included in -the Omnibus build. - -The Omnibus builds are created using container images [that use the `golang-fips` compiler](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/blob/master/docker/snippets/go_fips). For -example, [this job](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/jobs/2363742108) created -the `registry.gitlab.com/gitlab-org/gitlab-omnibus-builder/centos_8_fips:3.3.1` image used to -build packages for RHEL 8. - -#### Add a new FIPS build for another Linux distribution - -First, you need to make sure there is an Omnibus builder image for the -desired Linux distribution. The images used to build Omnibus packages are -created with [Omnibus Builder images](https://gitlab.com/gitlab-org/gitlab-omnibus-builder). - -Review [this merge request](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/merge_requests/218). A -new image can be added by: - -1. Adding CI jobs with the `_fips` suffix (for example: `ubuntu_18.04_fips`). -1. Making sure the `Dockerfile` uses `Snippets.new(fips: fips).populate` instead of `Snippets.new.populate`. - -After this image has been tagged, add a new [CI job to Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/911fbaccc08398dfc4779be003ea18014b3e30e9/gitlab-ci-config/dev-gitlab-org.yml#L594-602). - -### Cloud Native GitLab (CNG) - -The Cloud Native GitLab CI pipeline generates images using several base images: - -- Debian -- The [Red Hat Universal Base Image (UBI)](https://developers.redhat.com/products/rhel/ubi) - -UBI images ship with the same OpenSSL package as those used by -RHEL. This makes it possible to build FIPS-compliant binaries without -needing RHEL. RHEL 8.2 ships a [FIPS-validated OpenSSL](https://access.redhat.com/articles/compliance_activities_and_gov_standards), but 8.5 is in -review for FIPS validation. - -[This merge request](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/981) -introduces a FIPS pipeline for CNG images. Images tagged for FIPS have the `-fips` suffix. For example, -the `webservice` container has the following tags: - -- `master` -- `master-ubi` -- `master-fips` - -#### Base images for FIPS Builds - -- Current: [UBI 9.5 Micro](https://gitlab.com/gitlab-org/build/CNG/-/blob/master/ci_files/variables.yml?ref_type=heads#L4) - -### Testing merge requests with a FIPS pipeline - -Merge requests that can trigger Package and QA, can trigger a FIPS package and a -Reference Architecture test pipeline. The base image used for the trigger is -Ubuntu 20.04 FIPS: - -1. Trigger `e2e:test-on-omnibus` job, if not already triggered. -1. On the `gitlab-omnibus-mirror` child pipeline, manually trigger `Trigger:package:fips`. -1. When the package job is complete, manually trigger the `RAT:FIPS` job. + + + + diff --git a/doc/development/fips_gitlab.md b/doc/development/fips_gitlab.md new file mode 100644 index 00000000000..b10893cfa0b --- /dev/null +++ b/doc/development/fips_gitlab.md @@ -0,0 +1,574 @@ +--- +stage: Create +group: Source Code +info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review. +--- + +# FIPS 140-2 and 140-3 + +FIPS is short for "Federal Information Processing Standard", which defines certain security practices for a "cryptographic module" (CM). A cryptographic +module is set of hardware, software, and/or firmware that implements approved security functions (including cryptographic algorithms and key generation) +and is contained within a cryptographic boundary. + +At GitLab, a cryptographic module almost always referrs to an embedded software component of another product or package release and is specific to a particular +version of a binary. For example, a particular version of Ubuntu Kernel Crypto API cryptographic module or the OpenSSL project's FIPS Provider. + +A module is validated after it completes testing by a NIST-certified laboratory and has an active certificate listed in the +[Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program). A cryptographic module must be compiled, +installed, and configured according to its CMVP security policy. + +## Why should you care? + +GitLab is committed to releasing software for our customers who are required to comply with FIPS 140-2 and 140-3. + +FIPS 140 is a requirement to do business within the U.S. public sector, as well as some non-U.S. public sector organizations and certain industries depending +on the use case (healthcare, banking, etc.). FIPS 140-2 and FIPS 140-3 requirements are applicable to all U.S. Federal agencies, including software they +purchase whether that be self-managed or cloud. Agencies must use cryptographic-based security systems to provide adequate information security for all +operations and assets as defined in 15 U.S.C. § 278g-3. + +Non-validated cryptography is currently viewed as providing no protection to the information or data. In effect, the data would be considered unprotected +plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 or FIPS 140-3 is applicable. In essence, if +cryptography is required, then it must be validated. Should the cryptographic module be revoked, use of that module is no longer permitted. + +The challenge is that the use of FIPS-validated modules requires use of specific versions of a software package or binary. Historically, some organizations +would pin or version-lock to maintain compliance. The problem is that these validated modules inevitably become vulnerable, and the long lead time associated +with obtaining validation for a new version means it is impractical to consistently achieve both federal mandates: + +- Use of validated modules. +- The timely mitigation of vulnerabilities. + +The regulatory environment and policymaking in this area is dynamic and requires close monitoring by GitLab. + +## Terms to avoid + +These phases are used extensively at GitLab and among software providers. However, we should aim to avoid using them and update our documentation. + +- "FIPS compliant" or "FIPS compliance": These are not official terms defined by NIST or CMVP and therefore should not be used because it leaves room for + ambiguity or subjective interpretations. + - Compliance with FIPS 140 requires adherence to the entire standard and all security requirements for cryptographic modules, including the strict use of + CMVP-validated modules, CMVP-approved security functions, CMVP-approved sensitive parameter generation and establishment methods, and CMVP approved + authentication mechanisms. + - This term is often synonymous with using "CMVP-approved security functions", which is only one aspect of the standard. + +## Terms to use + +The following [official terms and phrases](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/use-of-fips-140-2-logo-and-phrases) are approved for use by the CMVP. + +- "FIPS 140-2 Validated" or "FIPS-validated" when referring to cryptographic modules that have a CMVP certificate and number. +- "FIPS 140-2 Inside" or "FIPS inside" when referring to a product that embeds FIPS-validated modules, such as GitLab, a GitLab software component, or GitLab-distributed software. If a product has a FIPS 140-2 module internal to the product and uses a FIPS official logo, "FIPS 140-2 Inside" and the certificate number must also accompany the logo. +- "CMVP-approved security functions" or "FIPS-approved algorithms": While technically the latter is not an official phrase, it communicates the same thing and provides additional context to those who are unfamiliar with NIST terminology. This is referring to [NIST SP 800-140C](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Cr2.pdf) which specifies the CMVP-approved cryptographic algorithms and their authorized use cases. + +## GitLab implementation of FIPS 140 + +GitLab is a [SaaS First](https://handbook.gitlab.com/handbook/product/product-principles/#saas-first) company and, as such, we follow the latest guidance +from the [Federal Risk and Authorization Management Program (FedRAMP)](https://www.fedramp.gov/). FedRAMP requires cloud service providers to use +FIPS-validated cryptographic modules everywhere cryptography is required including for encryption, hashing, random number generation, and key generation. +However, per control SC-13 from the FedRAMP security controls baseline, it is acceptable to use a cryptographic module that is not FIPS-validated when: + +- A FIPS-validated version has a known vulnerability. +- A feature with vulnerability is in use. +- A non-FIPS version fixes the vulnerability. +- The non-FIPS version is submitted to NIST for FIPS validation. That is, listed under Modules In Process or Implementation Under Test on CMVP website. +- POA&M is added to track approval and deployment when ready. + +FedRAMP released a draft (read: subject to change) [Policy for Cryptographic Module Selection and Use](https://www.fedramp.gov/cryptographic-module/) which +aims to provide more practical implementation guidance. Notably, the preference to remediate known vulnerabilities through patches or updates over continuing +to use known-vulnerable software that is FIPS-validated because the presence of known vulnerabilities creates risks that outweigh the assurance value provided +through validation. + +As required by CSP01 in this draft policy, GitLab takes the stance of applying patches to cryptographic modules. The order of preference for cryptographic +module selection per CSP10 is as follows: + +1. Mitigate the vulnerability in the validated module. +1. Use an unvalidated module, in the following order of preference: + - Module is substantially similar to a FIPS-validated module; validated algorithm. + - FIPS validation in process for module; validated algorithm. + - Expired FIPS validation for a previously validated module; validated algorithm. + - Module not in FIPS validation process; validated algorithm. + - Algorithm is approved and tested but not yet validated, and the module is not in FIPS validation process. + +### How is this audited? + +Third party assessment organizations (3PAOs) validate the use of a FIPS-validated CM by: + +1. Checking the certificate number. +1. Validating that the CM is configured in an approved mode and only uses algorithms listed as approved in the CM’s security policy. + +GitLab also does internal continuous monitoring and, in the past, has contracted independent auditors to audit our software against the FIPS 140 standard. +Results are available in the Trust Center. + +## GitLab FIPS-approved software + +GitLab currently releases software for Omnibus (Linux package) deployments, cloud-native (Helm chart) deployments, GitLab Runner, security analyzers, and more. +As stated above, GitLab follows FedRAMP guidance and, as such, we strive to include FIPS 140-2 validated modules (FIPS inside) when possible but, at minimum, +includes FIPS-approved algorithms (CMVP-approved security functions). GitLab favors security over compliance in situations where it is not possible to achieve +both with respect to FIPS 140-2. + +### Unsupported features in FIPS mode + +Some GitLab features may not work when FIPS mode is enabled. The following features +are known to not work in FIPS mode. However, there may be additional features not +listed here that also do not work properly in FIPS mode: + +- [Container Scanning](../user/application_security/container_scanning/index.md) support for scanning images in repositories that require authentication. +- [Code Quality](../ci/testing/code_quality.md) does not support operating in FIPS-compliant mode. +- [Dependency scanning](../user/application_security/dependency_scanning/index.md) support for Gradle. +- [Solutions for vulnerabilities](../user/application_security/vulnerabilities/index.md#resolve-a-vulnerability) + for yarn projects. +- [Static Application Security Testing (SAST)](../user/application_security/sast/index.md) + supports a reduced set of [analyzers](../user/application_security/sast/index.md#fips-enabled-images) + when operating in FIPS-compliant mode. +- [Operational Container Scanning](../user/clusters/agent/vulnerabilities.md). + +Additionally, these package repositories are disabled in FIPS mode: + +- [Conan package repository](../user/packages/conan_repository/index.md). +- [Debian package repository](../user/packages/debian_repository/index.md). + +### Development guidelines + +Please refer to the information above and the GitLab [Cryptography Standard](https://handbook.gitlab.com/handbook/security/cryptographic-standard/). Reach out +to `#sec-assurance` with questions or open an MR if something needs to be clarified. + +Here are some guidelines for developing GitLab FIPS-approved software: + +- We should make most, if not all, cryptographic calls use a FIPS-validated OpenSSL ([example](https://docs.openssl.org/3.0/man7/fips_module/)), whether that + be: + - Embedded as part of an operating system or container base image (preferred). + - Standalone. + + OpenSSL 3.0 now makes it possible to use a CMVP-validated module called the OpenSSL FIPS Provider `fips.so` while also allowing security patches to the rest + of OpenSSL without invalidating the module (refer to [OpenSSL README-FIPS.md](https://github.com/openssl/openssl/blob/master/README-FIPS.md)). This is also + now available to consume on RHEL 9 and UBI9 + ([CMVP certificate #4746](https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4746.pdf)). +- We should avoid non-approved cryptographic algorithms (for example, MD5) and switch to an + [approved FIPS 140-3 algorithm](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program) (for example, SHA256). Because MD5 is + cryptographically broken, this is a good practice. +- There may be instances where a non-approved cryptographic algorithm can be used for non-cryptographic purposes. For example, SHA1 is not a FIPS 140-3 + algorithm, but because Git uses it for non-cryptographic purposes, we can use it. In these cases, we must document why it's not being used for + cryptographic purposes, or disable the feature outright. + +- Backwards compatibility. There may be some features where switching algorithms would break existing functionality. For example, the database stores + passwords encrypted with bcrypt, and these passwords cannot be re-encrypted without user help. + +1. GitLab has standardized on RHEL and UBI for its FIPS-approved software releases and we should use the patterns outline below for Ruby, Go, CNG, Omnibus, and other software such as Runner, Secure analyzers, etc. + +## Install GitLab with FIPS compliance + +This guide is specifically for public users or GitLab team members with a requirement +to run a production instance of GitLab that is FIPS compliant. This guide outlines +a hybrid deployment using elements from both Omnibus and our Cloud Native GitLab installations. + +### Prerequisites + +- Amazon Web Services account. Our first target environment is running on AWS, and uses other FIPS Compliant AWS resources. For many AWS resources, you must use a [FIPS specific endpoint](https://aws.amazon.com/compliance/fips/). +- Ability to run Ubuntu 20.04 machines for GitLab. Our first target environment uses the hybrid architecture. +- Advanced Search: GitLab does not provide a packaged Elastic or OpenSearch deployment. You must use a FIPS-compliant service or disable Advanced Search. + +### Set up a FIPS-enabled cluster + +You can use the [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to spin +up a FIPS-enabled cluster for development and testing. As mentioned in the prerequisites, these instructions use Amazon Web Services (AWS) +because that is the first target environment. + +#### Set up your environment + +To get started, your AWS account must subscribe to a FIPS-enabled Amazon +Machine Image (AMI) in the [AWS Marketplace console](https://repost.aws/knowledge-center/launch-ec2-marketplace-subscription). + +This example assumes that the `Ubuntu Pro 20.04 FIPS LTS` AMI by +`Canonical Group Limited` has been added your account. This operating +system is used for virtual machines running in Amazon EC2. + +#### Omnibus + +The simplest way to get a FIPS-enabled GitLab cluster is to use an Omnibus reference architecture. +See the [GET Quick Start Guide](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/docs/environment_quick_start_guide.md) +for more details. The following instructions build on the Quick Start and are also necessary for [Cloud Native Hybrid](#cloud-native-hybrid) installations. + +##### Terraform: Use a FIPS AMI + +GitLab team members can view more information in this internal handbook page on how to use FIPS AMI: +`https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#terraform---use-fips-ami` + +##### Ansible: Specify the FIPS Omnibus builds + +The standard Omnibus GitLab releases build their own OpenSSL library, which is +not FIPS-validated. However, we have nightly builds that create Omnibus packages +that link against the operating system's OpenSSL library. To use this package, +update the `gitlab_edition` and `gitlab_repo_script_url` fields in the Ansible +`vars.yml`. + +GitLab team members can view more information in this internal handbook page on Ansible (AWS): +`https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#ansible-aws` + +#### Cloud Native Hybrid + +A Cloud Native Hybrid install uses both Omnibus and Cloud Native GitLab +(CNG) images. The previous instructions cover the Omnibus part, but two +additional steps are needed to enable FIPS in CNG: + +1. Use a custom Amazon Elastic Kubernetes Service (EKS) AMI. +1. Use GitLab containers built with RedHat's Universal Base Image (UBI). + +##### Build a custom EKS AMI + +Because Amazon does not yet publish a FIPS-enabled AMI, you have to +build one yourself with Packer. + +Amazon publishes the following Git repositories with information about custom EKS AMIs: + +- [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami) +- [Sample EKS custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis/) + +This [GitHub pull request](https://github.com/awslabs/amazon-eks-ami/pull/898) makes +it possible to create an Amazon Linux 2 EKS AMI with FIPS enabled for Kubernetes v1.21. +To build an image: + +1. [Install Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli). +1. Run the following: + + ```shell + git clone https://github.com/awslabs/amazon-eks-ami + cd amazon-eks-ami + git fetch origin pull/898/head:fips-ami + git checkout fips-ami + AWS_DEFAULT_REGION=us-east-1 make 1.21-fips # Be sure to set the region accordingly + ``` + +If you are using a different version of Kubernetes, adjust the `make` +command and `Makefile` accordingly. + +When the AMI build is done, a new AMI should be created with a message +such as the following: + +```plaintext +==> Builds finished. The artifacts of successful builds are: +--> amazon-ebs: AMIs were created: +us-west-2: ami-0a25e760cd00b027e +``` + +In this example, the AMI ID is `ami-0a25e760cd00b027e`, but your value may +be different. + +Building a RHEL-based system with FIPS enabled should be possible, but +there is [an outstanding issue preventing the Packer build from completing](https://github.com/aws-samples/amazon-eks-custom-amis/issues/51). + +Because this builds a custom AMI based on a specific version of an image, you must periodically rebuild the custom AMI to keep current with the latest security patches and upgrades. + +##### Terraform: Use a custom EKS AMI + +GitLab team members can view more information in this internal handbook page on how to use a custom EKS AMI: +`https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#terraform---use-a-custom-eks-ami` + +##### Ansible: Use UBI images + +CNG uses a Helm Chart to manage which container images to deploy. To use UBI-based containers, edit the Ansible `vars.yml` to use custom +Charts variables: + +```yaml +all: + vars: + ... + gitlab_charts_custom_config_file: '/path/to/gitlab-environment-toolkit/ansible/environments/gitlab-10k/inventory/charts.yml' +``` + +Now create `charts.yml` in the location specified above and specify tags with a `-fips` suffix. + +See our [Charts documentation on FIPS](https://docs.gitlab.com/charts/advanced/fips/index.html) for more details, including +an [example values file](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/fips/values.yaml) as a reference. + +You can also use release tags, but the versioning is tricky because each +component may use its own versioning scheme. For example, for GitLab v15.2: + +```yaml +global: + image: + tagSuffix: -fips + certificates: + image: + tag: 20211220-r0 + kubectl: + image: + tag: 1.18.20 + +gitlab: + gitaly: + image: + tag: v15.2.0 + gitlab-exporter: + image: + tag: 11.17.1 + gitlab-shell: + image: + tag: v14.9.0 + gitlab-mailroom: + image: + tag: v15.2.0 + gitlab-pages: + image: + tag: v1.61.0 + migrations: + image: + tag: v15.2.0 + sidekiq: + image: + tag: v15.2.0 + toolbox: + image: + tag: v15.2.0 + webservice: + image: + tag: v15.2.0 + workhorse: + tag: v15.2.0 +``` + +## FIPS Performance Benchmarking + +The Quality Engineering Enablement team assists these efforts by checking if FIPS-enabled environments perform well compared to non-FIPS environments. + +Testing shows an impact in some places, such as Gitaly SSL, but it's not large enough to impact customers. + +You can find more information on FIPS performance benchmarking in the following issue: + +- [Benchmark performance of FIPS reference architecture](https://gitlab.com/gitlab-org/gitlab/-/issues/364051#note_1010450415) + +## Setting up a FIPS-enabled development environment + +The simplest approach is to set up a virtual machine running +[Red Hat Enterprise Linux 8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#switching-the-system-to-fips-mode_using-the-system-wide-cryptographic-policies). + +Red Hat provide free licenses to developers, and permit the CD image to be +downloaded from the [Red Hat developer's portal](https://developers.redhat.com). +Registration is required. + +After the virtual machine is set up, you can follow the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) +installation instructions, including the [advanced instructions for RHEL](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/advanced.md#red-hat-enterprise-linux). +The `asdf` tool is not used for dependency management because it's essential to +use the RedHat-provided Go compiler and other system dependencies. + +### Enable FIPS mode + +After GDK and its dependencies are installed, run this command (as +root) and restart the virtual machine: + +```shell +fips-mode-setup --enable +``` + +You can check whether it's taken effect by running: + +```shell +fips-mode-setup --check +``` + +In this environment, OpenSSL refuses to perform cryptographic operations +forbidden by the FIPS standards. This enables you to reproduce FIPS-related bugs, +and validate fixes. + +You should be able to open a web browser inside the virtual machine and sign in +to the GitLab instance. + +You can disable FIPS mode again by running this command, then restarting the +virtual machine: + +```shell +fips-mode-setup --disable +``` + +#### Detect FIPS enablement in code + +You can query `Gitlab::FIPS` in Ruby code to determine if the instance is FIPS-enabled: + +```ruby +def default_min_key_size(name) + if Gitlab::FIPS.enabled? + Gitlab::SSHPublicKey.supported_sizes(name).select(&:positive?).min || -1 + else + 0 + end +end +``` + +## Omnibus FIPS packages + +GitLab has a dedicated repository +([`gitlab/gitlab-fips`](https://packages.gitlab.com/gitlab/gitlab-fips)) +for builds of the Omnibus GitLab which are built with FIPS compliance. +These GitLab builds are compiled to use the system OpenSSL, instead of +the Omnibus-embedded version of OpenSSL. These packages are built for: + +- RHEL 8 (and compatible) +- AmazonLinux 2 +- Ubuntu + +These are [consumed by the GitLab Environment Toolkit](#install-gitlab-with-fips-compliance) (GET). + +See [the section on how FIPS builds are created](#how-fips-builds-are-created). + +### System Libgcrypt + +Because of a bug, FIPS Linux packages for GitLab 17.6 and earlier did not use the system +[Libgcrypt](https://www.gnupg.org/software/libgcrypt/index.html), but the same Libgcrypt +bundled with regular Linux packages. + +This issue is fixed for all FIPS Linux packages for GitLab 17.7, except for AmazonLinux 2. +The Libgcrypt version of AmazonLinux 2 is not compatible with the +[GPGME](https://gnupg.org/software/gpgme/index.html) and [GnuPG](https://gnupg.org/) +versions shipped with the FIPS Linux packages. + +FIPS Linux packages for AmazonLinux 2 will continue to use the same Libgcrypt bundled with +the regular Linux packages, otherwise we would have to downgrade GPGME and GnuPG. + +If you require full compliance, you must migrate to another operating +system for which FIPS Linux packages are available. + +### Nightly Omnibus FIPS builds + +The Distribution team has created [nightly FIPS Omnibus builds](https://packages.gitlab.com/gitlab/nightly-fips-builds), +which can be used for *testing* purposes. These should never be used for production environments. + +## Runner + +See the [documentation on installing a FIPS-compliant GitLab Runner](https://docs.gitlab.com/runner/install/#fips-compliant-gitlab-runner). + +## Verify FIPS + +The following sections describe ways you can verify if FIPS is enabled. + +### Kernel + +```shell +$ cat /proc/sys/crypto/fips_enabled +1 +``` + +### Ruby (Omnibus images) + +```ruby +$ /opt/gitlab/embedded/bin/irb +irb(main):001:0> require 'openssl'; OpenSSL.fips_mode +=> true +``` + +### Ruby (CNG images) + +```ruby +$ irb +irb(main):001:0> require 'openssl'; OpenSSL.fips_mode +=> true +``` + +### Go + +Google maintains a [`dev.boringcrypto` branch](https://github.com/golang/go/tree/dev.boringcrypto) in the Go compiler +that makes it possible to statically link BoringSSL, a FIPS-validated module forked from OpenSSL. However, +[BoringCrypto is not officially supported](https://go.dev/src/crypto/internal/boring/README), although it is used by other companies. + +GitLab uses [`golang-fips`](https://github.com/golang-fips/go), [a fork of the `dev.boringcrypto` branch](https://github.com/golang/go/blob/2fb6bf8a4a51f92f98c2ae127eff2b7ac392c08f/README.boringcrypto.md) to build Go programs that +[dynamically link OpenSSL via `dlopen`](https://github.com/golang-fips/go?tab=readme-ov-file#openssl-support). This has several advantages: + +- Using a FIPS-validated, system OpenSSL (RHEL/UBI) is straightforward. +- This is the source code used by the [Red Hat go-toolset package](https://gitlab.com/redhat/centos-stream/rpms/golang#sources). +- Unlike [go-toolset](https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-hat-enterprise-linux#), this fork appears to keep up with the latest Go releases. + +However, [cgo](https://pkg.go.dev/cmd/cgo) must be enabled via `CGO_ENABLED=1` for this to work. There +is a performance hit when calling into C code. + +Projects that are compiled with `golang-fips` on Linux x86 automatically +get built the crypto routines that use OpenSSL. While the `boringcrypto` +build tag is automatically present, no extra build tags are actually +needed. There are [specific build tags](https://github.com/golang-fips/go/blob/go1.18.1-1-openssl-fips/src/crypto/internal/boring/boring.go#L6) +that disable these crypto hooks. + +We can [check whether a given binary is using OpenSSL](https://go.googlesource.com/go/+/dev.boringcrypto/misc/boring/#caveat) via `go tool nm` +and look for symbols named `Cfunc__goboringcrypto` or `crypto/internal/boring/sig.BoringCrypto`. + +For example: + +```console +$ # Find in a Golang-FIPS 1.17 library +$ go tool nm nginx-ingress-controller | grep '_Cfunc__goboringcrypto_|\bcrypto/internal/boring/sig\.BoringCrypto' | tail + 2a0b650 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Final + 2a0b658 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Init + 2a0b660 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Update + 2a0b668 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Final + 2a0b670 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Init + 2a0b678 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Update + 2a0b680 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_sign + 2a0b688 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_verify + 2a0b690 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_error_string_n + 2a0b698 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_get_error +$ # Find in a Golang-FIPS 1.22 library +$ go tool nm tenctl | grep '_Cfunc__goboringcrypto_|\bcrypto/internal/boring/sig\.BoringCrypto' + 4cb840 t crypto/internal/boring/sig.BoringCrypto.abi0 +``` + +In addition, LabKit contains routines to [check whether FIPS is enabled](https://gitlab.com/gitlab-org/labkit/-/tree/master/fips). + +## How FIPS builds are created + +Many GitLab projects (for example: Gitaly, GitLab Pages) have +standardized on using `FIPS_MODE=1 make` to build FIPS binaries locally. + +### Omnibus + +The Omnibus FIPS builds are triggered with the `USE_SYSTEM_SSL` +environment variable set to `true`. When this environment variable is +set, the Omnibus recipes dependencies such as `curl`, NGINX, and libgit2 +will link against the system OpenSSL. OpenSSL will NOT be included in +the Omnibus build. + +The Omnibus builds are created using container images [that use the `golang-fips` compiler](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/blob/master/docker/snippets/go_fips). For +example, [this job](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/jobs/2363742108) created +the `registry.gitlab.com/gitlab-org/gitlab-omnibus-builder/centos_8_fips:3.3.1` image used to +build packages for RHEL 8. + +#### Add a new FIPS build for another Linux distribution + +First, you need to make sure there is an Omnibus builder image for the +desired Linux distribution. The images used to build Omnibus packages are +created with [Omnibus Builder images](https://gitlab.com/gitlab-org/gitlab-omnibus-builder). + +Review [this merge request](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/merge_requests/218). A +new image can be added by: + +1. Adding CI jobs with the `_fips` suffix (for example: `ubuntu_18.04_fips`). +1. Making sure the `Dockerfile` uses `Snippets.new(fips: fips).populate` instead of `Snippets.new.populate`. + +After this image has been tagged, add a new [CI job to Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/911fbaccc08398dfc4779be003ea18014b3e30e9/gitlab-ci-config/dev-gitlab-org.yml#L594-602). + +### Cloud Native GitLab (CNG) + +The Cloud Native GitLab CI pipeline generates images using several base images: + +- Debian +- The [Red Hat Universal Base Image (UBI)](https://developers.redhat.com/products/rhel/ubi) + +UBI images ship with the same OpenSSL package as those used by +RHEL. This makes it possible to build FIPS-compliant binaries without +needing RHEL. RHEL 8.2 ships a [FIPS-validated OpenSSL](https://access.redhat.com/articles/compliance_activities_and_gov_standards), but 8.5 is in +review for FIPS validation. + +[This merge request](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/981) +introduces a FIPS pipeline for CNG images. Images tagged for FIPS have the `-fips` suffix. For example, +the `webservice` container has the following tags: + +- `master` +- `master-ubi` +- `master-fips` + +#### Base images for FIPS Builds + +- Current: [UBI 9.5 Micro](https://gitlab.com/gitlab-org/build/CNG/-/blob/master/ci_files/variables.yml?ref_type=heads#L4) + +### Testing merge requests with a FIPS pipeline + +Merge requests that can trigger Package and QA, can trigger a FIPS package and a +Reference Architecture test pipeline. The base image used for the trigger is +Ubuntu 20.04 FIPS: + +1. Trigger `e2e:test-on-omnibus` job, if not already triggered. +1. On the `gitlab-omnibus-mirror` child pipeline, manually trigger `Trigger:package:fips`. +1. When the package job is complete, manually trigger the `RAT:FIPS` job. diff --git a/doc/security/hardening_nist_800_53.md b/doc/security/hardening_nist_800_53.md index 60f1653d68e..2369f9fddf6 100644 --- a/doc/security/hardening_nist_800_53.md +++ b/doc/security/hardening_nist_800_53.md @@ -638,9 +638,9 @@ scanners [support CycloneDX formatted reports](../ci/yaml/artifacts_reports.md#a Compliance programs based on NIST 800-53, such as FedRAMP, require FIPS compliance for all applicable cryptographic modules. GitLab has released FIPS versions of its container images and provides guidance on -[how to configure GitLab to meet FIPS compliance standards](../development/fips_compliance.md). +[how to configure GitLab to meet FIPS compliance standards](../development/fips_gitlab.md). It is important to note that -[certain features are not available or supported in FIPS mode](../development/fips_compliance.md#unsupported-features-in-fips-mode). +[certain features are not available or supported in FIPS mode](../development/fips_gitlab.md#unsupported-features-in-fips-mode). While GitLab provides FIPS-compliant images, it is the responsibility of the customer to configure underlying infrastructure and evaluate the diff --git a/doc/security/password_storage.md b/doc/security/password_storage.md index e76c8408350..16cbd86369a 100644 --- a/doc/security/password_storage.md +++ b/doc/security/password_storage.md @@ -15,7 +15,7 @@ GitLab administrators can configure how passwords and OAuth tokens are stored. ## Password storage > - PBKDF2+SHA512 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360658) in GitLab 15.2 [with flags](../administration/feature_flags.md) named `pbkdf2_password_encryption` and `pbkdf2_password_encryption_write`. Disabled by default. -> - Feature flags [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/101691) in GitLab 15.6 and PBKDF2+SHA512 was made available to all GitLab instances running in [FIPS mode](../development/fips_compliance.md). +> - Feature flags [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/101691) in GitLab 15.6 and PBKDF2+SHA512 was made available to all GitLab instances running in [FIPS mode](../development/fips_gitlab.md). GitLab stores user passwords in a hashed format to prevent passwords from being stored as plain text. @@ -29,7 +29,7 @@ library to hash user passwords. Created password hashes have these attributes: strong and industry-standard. - **PBKDF2+SHA512**: PBKDF2+SHA512 is supported: - In GitLab 15.2 to GitLab 15.5 when `pbkdf2_password_encryption` and `pbkdf2_password_encryption_write` [feature flags](../administration/feature_flags.md) are enabled. - - In GitLab 15.6 and later when [FIPS mode](../development/fips_compliance.md) is enabled (feature flags are not required). + - In GitLab 15.6 and later when [FIPS mode](../development/fips_gitlab.md) is enabled (feature flags are not required). - **Stretching**: Password hashes are [stretched](https://en.wikipedia.org/wiki/Key_stretching) to harden against brute-force attacks. By default, GitLab uses a stretching factor of 10 for bcrypt and 20,000 for PBKDF2 + SHA512. diff --git a/doc/update/package/index.md b/doc/update/package/index.md index b705f1a3fe0..2928169179f 100644 --- a/doc/update/package/index.md +++ b/doc/update/package/index.md @@ -66,7 +66,7 @@ Six repositories are maintained: [Enterprise Edition](https://about.gitlab.com/pricing/) ones. - [`gitlab/gitlab-ce`](https://packages.gitlab.com/gitlab/gitlab-ce): A stripped down package that contains only the Community Edition features. -- [`gitlab/gitlab-fips`](https://packages.gitlab.com/gitlab/gitlab-fips): [FIPS-compliant](../../development/fips_compliance.md) builds. +- [`gitlab/gitlab-fips`](https://packages.gitlab.com/gitlab/gitlab-fips): [FIPS-compliant](../../development/fips_gitlab.md) builds. - [`gitlab/unstable`](https://packages.gitlab.com/gitlab/unstable): Release candidates and other unstable versions. - [`gitlab/nightly-builds`](https://packages.gitlab.com/gitlab/nightly-builds): Nightly builds. - [`gitlab/raspberry-pi2`](https://packages.gitlab.com/gitlab/raspberry-pi2): Official Community Edition releases built for [Raspberry Pi](https://www.raspberrypi.org) packages. diff --git a/doc/update/versions/gitlab_17_changes.md b/doc/update/versions/gitlab_17_changes.md index 37b8da9257b..f9e485883b0 100644 --- a/doc/update/versions/gitlab_17_changes.md +++ b/doc/update/versions/gitlab_17_changes.md @@ -237,7 +237,7 @@ ensure that your proxy server does not alter or remove signed HTTP headers. - Git 2.47.0 and later is required by Gitaly. For installations from source, you should use the [Git version provided by Gitaly](../../install/installation.md#git). - FIPS Linux packages now use the system Libgcrypt, except FIPS Linux packages for AmazonLinux 2. Previous versions of the FIPS Linux packages used the same Libgcrypt used by the regular Linux packages, which was a bug. For more information, see - [the FIPS documentation](../../development/fips_compliance.md#system-libgcrypt). + [the FIPS documentation](../../development/fips_gitlab.md#system-libgcrypt). - Linux `gitlab-runner` packages have broken out `gitlab-runner-helper-images` as a new required dependency. If you manually install `gitlab-runner` packages for upgrades, be sure to also [download the helper images manually](https://docs.gitlab.com/runner/install/linux-manually/#download). diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index 00e0776116c..652e5014cb9 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -209,7 +209,7 @@ variables: AWS_DEFAULT_REGION: ``` -Authenticating to a remote registry is not supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is enabled. +Authenticating to a remote registry is not supported when [FIPS mode](../../../development/fips_gitlab.md#enable-fips-mode) is enabled. #### Report language-specific findings @@ -266,8 +266,8 @@ positives. | `CS_IMAGE_SUFFIX` | `""` | Suffix added to `CS_ANALYZER_IMAGE`. If set to `-fips`, `FIPS-enabled` image is used for scan. See [FIPS-enabled images](#fips-enabled-images) for more details. | | `CS_QUIET` | `""` | If set, this variable disables output of the [vulnerabilities table](#container-scanning-job-log-format) in the job log. [Introduced](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/merge_requests/50) in GitLab 15.1. | | `CS_REGISTRY_INSECURE` | `"false"` | Allow access to insecure registries (HTTP only). Should only be set to `true` when testing the image locally. Works with all scanners, but the registry must listen on port `80/tcp` for Trivy to work. | -| `CS_REGISTRY_PASSWORD` | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. The default is only set if `$CS_IMAGE` resides at [`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md). Not supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is enabled. | -| `CS_REGISTRY_USER` | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. The default is only set if `$CS_IMAGE` resides at [`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md). Not supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is enabled. | +| `CS_REGISTRY_PASSWORD` | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. The default is only set if `$CS_IMAGE` resides at [`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md). Not supported when [FIPS mode](../../../development/fips_gitlab.md#enable-fips-mode) is enabled. | +| `CS_REGISTRY_USER` | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. The default is only set if `$CS_IMAGE` resides at [`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md). Not supported when [FIPS mode](../../../development/fips_gitlab.md#enable-fips-mode) is enabled. | | `CS_SEVERITY_THRESHOLD` | `UNKNOWN` | Severity level threshold. The scanner outputs vulnerabilities with severity level higher than or equal to this threshold. Supported levels are `UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, and `CRITICAL`. **{warning}** **[Default value changed to `MEDIUM`](https://gitlab.com/gitlab-org/gitlab/-/issues/439782)** in GitLab 17.8. | | `CS_TRIVY_JAVA_DB` | `"registry.gitlab.com/gitlab-org/security-products/dependencies/trivy-java-db"` | Specify an alternate location for the [trivy-java-db](https://github.com/aquasecurity/trivy-java-db) vulnerability database. | | `SECURE_LOG_LEVEL` | `info` | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. | @@ -309,7 +309,7 @@ standard tag plus the `-fips` extension. NOTE: The `-fips` flag is automatically added to `CS_ANALYZER_IMAGE` when FIPS mode is enabled in the GitLab instance. -Container scanning of images in authenticated registries is not supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) +Container scanning of images in authenticated registries is not supported when [FIPS mode](../../../development/fips_gitlab.md#enable-fips-mode) is enabled. When `CI_GITLAB_FIPS_MODE` is `"true"`, and `CS_REGISTRY_USER` or `CS_REGISTRY_PASSWORD` is set, the analyzer exits with an error and does not perform the scan. @@ -613,7 +613,7 @@ Also: - Consider creating credentials with read-only permissions and rotating them regularly if the options aren't selected. -Scanning images in external private registries is not supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is enabled. +Scanning images in external private registries is not supported when [FIPS mode](../../../development/fips_gitlab.md#enable-fips-mode) is enabled. #### Create and use a Trivy Java database mirror diff --git a/doc/user/application_security/coverage_fuzzing/index.md b/doc/user/application_security/coverage_fuzzing/index.md index 0c4f7dffb87..bf22fa100b7 100644 --- a/doc/user/application_security/coverage_fuzzing/index.md +++ b/doc/user/application_security/coverage_fuzzing/index.md @@ -317,7 +317,7 @@ The `covfuzz-ci.yml` is the same as that in the [original synchronous example](h ## FIPS-enabled binary -[Starting in GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/352549) the coverage fuzzing binary is compiled with `golang-fips` on Linux x86 and uses OpenSSL as the cryptographic backend. For more details, see [FIPS compliance at GitLab with Go](../../../development/fips_compliance.md#go). +[Starting in GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/352549) the coverage fuzzing binary is compiled with `golang-fips` on Linux x86 and uses OpenSSL as the cryptographic backend. For more details, see [FIPS compliance at GitLab with Go](../../../development/fips_gitlab.md#go). ## Offline environment diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md index abf8a4087c4..87c11bf7f78 100644 --- a/doc/user/application_security/vulnerabilities/index.md +++ b/doc/user/application_security/vulnerabilities/index.md @@ -457,7 +457,7 @@ The following scanners are supported by this feature: - [Dependency Scanning](../dependency_scanning/index.md). Automatic patch creation is only available for Node.js projects managed with - `yarn`. Also, Automatic patch creation is only supported when [FIPS mode](../../../development/fips_compliance.md#enable-fips-mode) is disabled. + `yarn`. Also, Automatic patch creation is only supported when [FIPS mode](../../../development/fips_gitlab.md#enable-fips-mode) is disabled. - [Container Scanning](../container_scanning/index.md). To resolve a vulnerability, you can either: diff --git a/doc/user/clusters/agent/vulnerabilities.md b/doc/user/clusters/agent/vulnerabilities.md index b511bd231c3..00e28794237 100644 --- a/doc/user/clusters/agent/vulnerabilities.md +++ b/doc/user/clusters/agent/vulnerabilities.md @@ -282,7 +282,7 @@ To scan private images, the scanner relies on the image pull secrets (direct ref In GitLab agent 16.9 and later, operational container scanning: - Handles Trivy reports of up to 100 MB. For previous releases, this limit is 10 MB. -- Is [disabled](../../../development/fips_compliance.md#unsupported-features-in-fips-mode) when the GitLab agent runs in `fips` mode. +- Is [disabled](../../../development/fips_gitlab.md#unsupported-features-in-fips-mode) when the GitLab agent runs in `fips` mode. ## Troubleshooting diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md index 1ed19518734..a52fc4b3253 100644 --- a/doc/user/packages/conan_repository/index.md +++ b/doc/user/packages/conan_repository/index.md @@ -17,7 +17,7 @@ limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/ work and timelines to make it production ready. NOTE: -The Conan registry is not FIPS compliant and is disabled when [FIPS mode](../../../development/fips_compliance.md) is enabled. +The Conan registry is not FIPS compliant and is disabled when [FIPS mode](../../../development/fips_gitlab.md) is enabled. Publish Conan packages in your project's package registry. Then install the packages whenever you need to use them as a dependency. diff --git a/locale/gitlab.pot b/locale/gitlab.pot index a11b016fc7c..4d5e16b2bc0 100644 --- a/locale/gitlab.pot +++ b/locale/gitlab.pot @@ -6875,6 +6875,9 @@ msgstr "" msgid "Analytics|Dates and times are displayed in the UTC timezone" msgstr "" +msgid "Analytics|Default date range '%{defaultOption}' is not included in the list of dateRange options" +msgstr "" + msgid "Analytics|Edit" msgstr "" @@ -18849,6 +18852,9 @@ msgstr "" msgid "Date range" msgstr "" +msgid "Date range filter validation" +msgstr "" + msgid "Date range limited to %d day" msgid_plural "Date range limited to %d days" msgstr[0] "" diff --git a/qa/qa/scenario/test/instance/all.rb b/qa/qa/scenario/test/instance/all.rb index c1da7a1b91f..5f189b820c8 100644 --- a/qa/qa/scenario/test/instance/all.rb +++ b/qa/qa/scenario/test/instance/all.rb @@ -20,7 +20,6 @@ module QA relative-url decomposition-single-db decomposition-multiple-db - git-sha256-repositories ], test_on_omnibus: %w[ instance diff --git a/spec/frontend/blob/components/__snapshots__/blob_header_filepath_spec.js.snap b/spec/frontend/blob/components/__snapshots__/blob_header_filepath_spec.js.snap deleted file mode 100644 index 6dad00e4bc6..00000000000 --- a/spec/frontend/blob/components/__snapshots__/blob_header_filepath_spec.js.snap +++ /dev/null @@ -1,36 +0,0 @@ -// Jest Snapshot v1, https://goo.gl/fbAQLP - -exports[`Blob Header Filepath rendering matches the snapshot 1`] = ` -
-
-`; diff --git a/spec/frontend/blob/components/blob_header_filepath_spec.js b/spec/frontend/blob/components/blob_header_filepath_spec.js index f069a038840..f3699328b95 100644 --- a/spec/frontend/blob/components/blob_header_filepath_spec.js +++ b/spec/frontend/blob/components/blob_header_filepath_spec.js @@ -22,15 +22,9 @@ describe('Blob Header Filepath', () => { }); } - const getById = (id) => wrapper.findByTestId(id); const findBadge = () => wrapper.findComponent(GlBadge); describe('rendering', () => { - it('matches the snapshot', () => { - createComponent(); - expect(wrapper.element).toMatchSnapshot(); - }); - it('renders regular name', () => { createComponent(); expect(wrapper.find('.js-blob-header-filepath').text().trim()).toBe(MockBlob.path); @@ -60,20 +54,6 @@ describe('Blob Header Filepath', () => { expect(wrapper.find('small').exists()).toBe(false); }); - it('should have classes by default', () => { - createComponent(); - expect(getById('file-title-content').attributes('class')).toEqual( - 'file-title-name mr-1 js-blob-header-filepath gl-break-all gl-font-bold', - ); - }); - - it('should have classes when shown as a link', () => { - createComponent({}, {}, { showAsLink: true }); - expect(getById('file-title-content').attributes('class')).toEqual( - 'file-title-name mr-1 js-blob-header-filepath gl-break-all gl-font-bold !gl-text-blue-700 hover:gl-cursor-pointer', - ); - }); - it('renders LFS badge if LFS if enabled', () => { createComponent({ storedExternally: true, externalStorage: 'lfs' }); expect(findBadge().text()).toBe('LFS');