Provide an easier out of the box experience for air-gapped or isolated instances

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Label this issue
• Close this issue

Overview

By default, many GitLab features (such as SAST, the Runner itself and so on) pull images from various locations. Quite a few are from the official GitLab.com container registry, but others can be hosted on third party registries as well. This poses a challenge for our customers who would like to either reduce the potential failure modes (third party service going down), or those whose instances are not connected to the internet.

We do offer some documentation on how to operate "offline environments" but we leave much of the effort to the customer on how to implement and customize their environment to support this: https://docs.gitlab.com/ee/user/application_security/offline_deployments/.

Opportunity

Rather than requiring customers to patch together their offline environment support themselves, we could consider ways in making the offline environment easier to configure or perhaps even the default. This could offer a few advantages:

1. Reduced cloud spend for GitLab, Inc, as customers would be pulling images from their local GitLab servers rather than GitLab.com. We know that our secure analyzers are some of the highest drivers of transfer cost for our .com registry.
2. Reduced dependencies on upstream services and internet connectivity for features to function. Today, our features which depend on GitLab.com or third party hosted images can fail if either GitLab.com goes down, or if their upstream internet connectivity is impacted.
3. Faster time to value and less operational complexity for our customers who need offline environments. If we make this easier to configure (or the default) we would lessen the burden on this customer segment, rather than following along documentation and in some cases features where it may not be supported.

Potential solutions

There are two main areas to think about in terms of a technical solution.

Shipping image dependencies

We could:

• Bake in the current images during version creation/tagging. Perhaps this could be an optional package/image included, or flag for the charts.
• Offer some easy synchronization tool to periodically sync or sneakernet in files.

Adjusting CI templates

• We could adjust the official CI templates to pull from a variable defined registry path, rather than a hardcoded one. (I.e. $CI_REGISTRY or something)