Create air-gapped specific templates for Secure Products
NOTE if you are a user who also would like to see this feature, please UPVOTE
Problem to solve
Each Secure product has separate configuration required to enable scans in an air-gapped environment.
If we believe that a customer who wants to use one Secure product will want to use many, then it is likely in the interest of the customer, the Secure Team, and of those within GitLab who support customers, that Secure products are installed and configured using a consistent approach.
This issue presents one such way of approaching Secure product install and configuration.
This issue has been created based on feedback from a customer, and from GitLab Technical Account Managers.
Intended users
Proposal
Each Secure Team is currently ensuring that each product can work in an air-gapped environment. Configuration for each product will likely be a combination of overwriting CI Job variables in Secure templates (e.g. setting image
to the offline image) and using environment variables.
We can make this even better by doing the following:
1. Document consistent install instructions
The gitlab.yml
file in gitlab-rails
contains configuration for the registry
. The host
and port
are used to create the environment variable CI_REGISTRY
that is available in CI build jobs.
The customer should be instructed to fetch all of the Secure Docker images and their dependencies (dast:1
, klar:2
, arminc/clair-db:latest
, etc). They should then push them to their CI_REGISTRY
into a the namespace gitlab-secure
.
2. Using air-gapped template files
New air-gapped templates should be created for each Secure product. These should live in the lib/gitlab/ci/templates
directory of gitlab-rails
so that customers can easily add a Secure scan:
include:
- template: Container-Scanning.air-gapped.gitlab-ci.yml
- template: SAST.air-gapped.gitlab-ci.yml
- template: Dependency-Scanning.air-gapped.gitlab-ci.yml
- template: DAST.air-gapped.gitlab-ci.yml
- template: License-Scanning.air-gapped.gitlab-ci.yml
Each air-gapped
template can hopefully be concise, as it will delegate to the normal template:
e.g. Container-Scanning.air-gapped.gitlab-ci.yml
include:
- template: Container-Scanning.gitlab-ci.yml
container_scanning:
image: $CI_REGISTRY/gitlab-secure/klar:2
variables:
CLAIR_DB_IMAGE: $CI_REGISTRY/gitlab-secure/clair-db:latest
Known advantages
- If the configuration options support air-gapped execution for a Secure product, these may be encapsulated in the new template, allowing change on the GitLab end without affecting the customer
- Customers get install instructions/run a scan instructions that are consistent across Secure Products
- Running a scan becomes a one-liner
- For complicated setups, the CI Job attributes can still be overridden (e.g. image, variables)
- It is much easier for GitLab support teams to support Secure products (this is an assumption on the author's part)
Known disadvantages
- Customers may not have the
registry
configured in their air-gapped setup. We should verify this before attempting any engineering.