Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
a5850f2839
commit
ebe38b0808
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
4064e55eea5f1bb415cb57e8aa23630b14d7e387
|
||||
0173c7eadd49ca64bdd04aa2cc2b47607b09988b
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
8a9909381cf05e2d68b28d123337ba8c7bc5da30
|
||||
bb5dd9c7ced8de9cf7f5405a34836e6fb7f8e8a4
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ export default {
|
|||
<component
|
||||
:is="showAsLink ? 'gl-link' : 'strong'"
|
||||
v-bind="linkHref"
|
||||
class="file-title-name mr-1 js-blob-header-filepath gl-break-all gl-font-bold"
|
||||
class="file-title-name js-blob-header-filepath gl-mr-1 gl-break-all gl-font-bold gl-text-strong"
|
||||
:class="{ '!gl-text-blue-700 hover:gl-cursor-pointer': showAsLink }"
|
||||
data-testid="file-title-content"
|
||||
>{{ fileName }}</component
|
||||
|
|
@ -79,7 +79,7 @@ export default {
|
|||
css-class="gl-mr-2"
|
||||
/>
|
||||
|
||||
<small v-if="showBlobSize" class="gl-mr-3">{{ blobSize }}</small>
|
||||
<small v-if="showBlobSize" class="gl-mr-3 gl-text-subtle">{{ blobSize }}</small>
|
||||
|
||||
<gl-badge v-if="showLfsBadge">{{ __('LFS') }}</gl-badge>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@
|
|||
|
||||
i {
|
||||
cursor: pointer;
|
||||
color: var(--gray-200, $gray-200);
|
||||
@apply gl-text-disabled;
|
||||
padding-right: 10px;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1038,7 +1038,7 @@ $ide-commit-header-height: 48px;
|
|||
|
||||
.terminal-wrapper {
|
||||
background: $black;
|
||||
color: $gray-200;
|
||||
@apply gl-text-disabled;
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
.user-search-btn {
|
||||
top: 1px;
|
||||
color: $gray-200;
|
||||
@apply gl-text-disabled;
|
||||
background: transparent;
|
||||
border: 0;
|
||||
outline: 0;
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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" }
|
||||
|
|
|
|||
|
|
@ -39323,6 +39323,7 @@ Conversation type of the thread.
|
|||
| Value | Description |
|
||||
| ----- | ----------- |
|
||||
| <a id="aiconversationsthreadsconversationtypeduo_chat"></a>`DUO_CHAT` | duo_chat thread. |
|
||||
| <a id="aiconversationsthreadsconversationtypeduo_code_review"></a>`DUO_CODE_REVIEW` | duo_code_review thread. |
|
||||
|
||||
### `AiFeatureProviders`
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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. |
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
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.
|
||||
<!-- This redirect file can be deleted after <2025-04-29>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ variables:
|
|||
AWS_DEFAULT_REGION: <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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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] ""
|
||||
|
|
|
|||
|
|
@ -20,7 +20,6 @@ module QA
|
|||
relative-url
|
||||
decomposition-single-db
|
||||
decomposition-multiple-db
|
||||
git-sha256-repositories
|
||||
],
|
||||
test_on_omnibus: %w[
|
||||
instance
|
||||
|
|
|
|||
|
|
@ -1,36 +0,0 @@
|
|||
// Jest Snapshot v1, https://goo.gl/fbAQLP
|
||||
|
||||
exports[`Blob Header Filepath rendering matches the snapshot 1`] = `
|
||||
<div
|
||||
class="file-header-content gl-flex gl-items-center gl-leading-1"
|
||||
>
|
||||
<file-icon-stub
|
||||
aria-hidden="true"
|
||||
cssclasses="gl-mr-3"
|
||||
filemode=""
|
||||
filename="foo/bar/dummy.md"
|
||||
size="16"
|
||||
/>
|
||||
<strong
|
||||
class="file-title-name gl-break-all gl-font-bold js-blob-header-filepath mr-1"
|
||||
data-testid="file-title-content"
|
||||
>
|
||||
foo/bar/dummy.md
|
||||
</strong>
|
||||
<clipboard-button-stub
|
||||
category="tertiary"
|
||||
cssclass="gl-mr-2"
|
||||
gfm="\`foo/bar/dummy.md\`"
|
||||
size="medium"
|
||||
text="foo/bar/dummy.md"
|
||||
title="Copy file path"
|
||||
tooltipplacement="top"
|
||||
variant="default"
|
||||
/>
|
||||
<small
|
||||
class="gl-mr-3"
|
||||
>
|
||||
a lot
|
||||
</small>
|
||||
</div>
|
||||
`;
|
||||
|
|
@ -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');
|
||||
|
|
|
|||
Loading…
Reference in New Issue