Skip to content

Outbound request filtering controls

Release notes

In order to protect against the risk of data loss and exposure, outbound request filtering controls provide additional protections for GitLab Self-managed and Dedicated SaaS administrators to safely manage their instances.

You may block all requests with this setting and define accepted IP addresses and domains within an allowlist, to establish secure routes for outbound traffic.

Problem

Some customers are required to prevent the possibility of data being sent to non-company approved sources. One way this can happen if they use GitLab, is by features like: integrations, status checks, webhooks, streaming audit logs, and mirroring. Many of these features offer the ability to be administratively controlled, however not all. In these cases, another solution is required.

Proposed solution

GitLab already supports an outbound request filtering check in Rails: https://docs.gitlab.com/ee/security/webhooks.html. This feature is primarily intended to stop the ability for users to probe other adjacent systems on the local network. By default, local networks are blocked and an allowlist is available to permit specific hosts or IP ranges.

We could extend this system to offer an optional default block-all rule. When enabled, the only systems where egress would be allowed are those in the allowlist. This could be by domain, or by IP.

As part of this, we should also update the text to indicate it may not be only local networks blocked anymore. Best option may be to allow custom text, but that can be a follow on perhaps.

For a first MVC, we will add an additional checkbox that will filter out all requests. If this is enabled, then we will:

Alternative designs:

Scope

This feature is initially requested to be available at the instance level, because that is where the outbound requests settings currently live. This additional option however could be extended to top-level groups as well if requested.

Design source

✏ Figma project

Restricted features

I've gone through and validated that the following features are affected by the outgoing request filtering as they report such in the UI:

  • Streaming audit logs
  • Webhooks
  • GitHub Integration

The following features appear to be as blocked as well, but the UI did not explicitly report that they were filtered due to this check. The request simply failed. (When testing a remote system, they worked.)

  • Status checks
  • Jenkins integration

Limitation

This check is applied in Rails, so it will affect our Rails codebase. While this is the vast majority of our features, we do have some non-Rails processes such as the registry or gitaly. This should not be a reason not to implement this however, because:

  • These services could always be extended support in the future, as needed
  • There are other ways to control the outbound traffic for these services, such as by disabling mirroring or dependency proxy.

These limitations should be added to the documentation #377371 (comment 1295993205).

Customer Impact

This impacts customers with high sensitivity to regulations/compliance, especially users of dedicated SaaS and Self-managed GitLab, however, self-managed GitLab users may be able to use firewalls to enable their own network protections. You don't get a firewall with Dedicated SaaS GitLab, would never work for GitLab.com. For Dedicated SaaS, there is no workaround.

RICE Score

4.8

Integrations Planning Sheet

Engineering Effort

Availability & Testing

Suggestions

  • Validate that it is impossible to break signing in from blocking all requests.
  • Consider documenting if the customer may need to allow IPv6 and IPv4 versions when using an IP in the allowlist.
  • Investigate if other outbound requests not using Gitlab::HTTP are acceptable (CDN, gravatar, etc).
  • Writing unit tests around all service usages of Gitlab::HTTP could be a good way to lock down this feature, but if impractical it may be worth writing unit tests around some of the higher risk usages.
Edited by Grant Hickman