Geo: Silent mode - suppress outbound project, group, and system webhook traffic
Problem to solve
When testing a GitLab instance with Silent mode that has Project Webhooks, Group Webhooks, or System Hooks configured, events can generate outbound traffic and notification to external services. This is undesirable and can confuse end users and systems that have registered these webhooks that might think these notifications are coming from on the production instance.
Silent mode is designed to allow admins to suppress outbound communications from a GitLab instance and perform a range of tests against that instance without these tests generating egress webhook traffic.
Intended users
User experience goal
- Project, Group, and System webhooks registered with the instance should not send outbound traffic to their endpoints.
- Systems administrators should be confident that all egress project, group, and system webhook traffic is blocked.
Proposal
- When silent mode is enabled, block all outbound project and group webhook traffic. This step may or may not be completely handled by #410048 (closed).
- Deal with the downstream consequences of suppressing outgoing traffic where necessary for the MVC.
- For example, WebHookWorker jobs will raise an exception and be retried until max retries. These jobs should probably not be scheduled at all while silent mode is enabled.
- For example, Webhook trigger tests in UI will 500. It would be better to not attempt the action and return a flash message saying "Webhooks cannot be tested while Silent mode is enabled".
- If there are too many items to deal with, then open issues for each item, to discuss priority and/or direction.
Discovery Issue: #371816 (comment 1077369306))
Permissions and Security
This feature is tied to the silent mode setting which is protected by admin permissions.
Documentation
This feature will be documented as a subsection of the silent mode documentation.
Availability & Testing
We will need to ensure all outbound emails are suppress when silent mode is enabled. Emails come from a range of services within GitLab and it is important we ensure that all services and scenarios are covered.
Available Tier
- Free
- Premium/Silver
- Ultimate/Gold
Feature Usage Metrics
The metrics for this feature will be tied to metric of silent mode.
What does success look like, and how can we measure that?
We will measure the success of this feature in concert with the silent mode feature as this is one part of this large silent mode feature.
Is this a cross-stage feature?
No
What is the competitive advantage or differentiation for this feature?
Competitive advantage for this feature will be align with that of the silent mode feature itself of which this is a part of.
comment)
Proposed solution (fromTo prevent WebHookWorker
s from being queued during silent mode, we can update the .disabled
and .executable
scopes in WebHooks::AutoDisabling
to return all
in .disabled
and none
in .executable
when silent mode is enabled.
We can also add a second check similar to WebHookService#disabled?
to return an error when silent mode is enabled. This will turn any queued workers into a no-op, and additionally affect integrations that use webhooks (integrations that include the Integrations::HasWebHook
module.)
# def execute
return ServiceResponse.error(message: 'Hook cannot execute when silent mode is enabled') if silent_mode_enabled?
I nearly forgot about File Hooks - we have the oft-forgotten file hooks feature which are outside of the WebHook
model and are literally arbitrary files on the instance that are executed.
For those, we'd probably need to return an empty array in .dir_glob
when silent mode is enabled, and additionally return early in FileHookWorker
.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.