## 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: - [:frame_photo: Show a warning alert (see mockup)](https://gitlab.com/gitlab-org/gitlab/-/issues/377371/designs/proposal.png) - [:frame_photo: Display an Info alert on the bottom of each individual integration page](https://gitlab.com/gitlab-org/gitlab/-/issues/377371/designs/Example_on_integration_-_bottom.png) - [:frame_photo: Display an Info alert on the bottom of webhook page](https://gitlab.com/gitlab-org/gitlab/-/issues/377371/designs/Example_on_webhook_-_bottom.png) **Alternative designs:** - [:frame_photo: Position the Info alert at the top of the pages](https://gitlab.com/gitlab-org/gitlab/-/issues/377371/designs/Example_on_integration_-_info.png) ### 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 :pencil2: [Figma project](https://www.figma.com/file/AyRQZAmZtnzQ6dUkzatE1v/Add-optional-default-block-all-rule-to-outbound-filtering-(%23377371)?node-id=3153%3A8818&t=hKCwku3J6aq88C56-1) ### 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 https://gitlab.com/gitlab-org/gitlab/-/issues/377371#note_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. - [Ultimate, Dedicated SaaS, 8000](https://gitlab.my.salesforce.com/0016100000K8R8f?srPos=0&srKp=001) - [Premium, SaaS & Self-managed, 14000](https://gitlab.my.salesforce.com/00161000004zrG3) ### RICE Score `4.8` [Integrations Planning Sheet](https://docs.google.com/spreadsheets/d/1mi32RvxZdhDh-ukyZQ2ssFqhmjdwVYrcxk8DRWgEamc/edit?usp=sharing) ### Engineering Effort - ~backend `3` - ~frontend `1` ### 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. <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance. Quad Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/#test-planning -->