GitLab Next

Problem to solve

The Web Application Firewall can passively monitor requests and can report if there is a possible security violation. This is great, but it is not preventing the attacker from unintended data access.

When the problem is reported and addressed, it could be too late as the damage from the attack may already be done.

WAF has also another mode: blocking. With this mode, malicious requests are blocked and they cannot reach the application, protecting from unauthorized access.

We should allow people to activate this mode, even if it is not the default.

Further details

Blocking mode has risks to block legitimate requests in case of false positives. Normally this is a blocker for its adoption, but this feature is still useful in security-critical environments. Users may want to leave it disabled during a "training and tuning" of the rules, and turn it on when they are confident that false positives have a very low rate. That is why this behavior should be opt-in, rather than opt-out, as our Defend principles specify

Personas

The main persona of this capability will be Sam or Sydney. This will be used as part of their job of monitoring and maintaining Kubernetes clusters for their apps.

Proposal

Allow users to toggle blocking mode on the WAF. The default should remain detection only if no user action is taken.

• What is the best way to present this toggle to the user? I propose we introduce it as a 'Manage' option under either the Ingress controller or introduce a new application.
• An environment variable will be used to enable this mode.
• When toggling, it must be possible to switch between states. That is, this should not be a one-time opt-in switch and then not possible to go back to reporting-only mode.

Documentation

Update the docs to describe:

• What blocking mode does compared to default.
• How to enable blocking mode.
• The potential impact of blocking mode.

What does success look like, and how can we measure that?

WAF with blocking mode enabled.

What is the type of buyer?

Core

---

Implementation plan

Status

• backend update ingress application chart to process modsecurity_snippet #28492 (closed) (MR !18047 (merged))
• backend Propagate AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE to Ingress resource configuration gitlab-org/charts/auto-deploy-app!12 (merged) gitlab-org/charts/auto-deploy-app!15 (merged)
• backend Update chart with modsecurity_snippet gitlab-org/charts/auto-deploy-app!12 (merged)
• backend Update auto-deploy-image to parse ENV into chart value gitlab-org/cluster-integration/auto-deploy-image!28 (merged)
• backend use custom modsecurity.conf to allow overriding SecRuleEngine !18485 (merged)
• frontend documentation document modsecurity ADO deployment variable !18293 (closed) !18809 (merged)

Decisions

• Limit blocking behavioral toggle per-project, not cluster-wide

• Use ENV variable based approach for initial feature toggle