modsecurity-snippet annotation is not validated in webhook validator

[angelbarrera92]

What happened:

The modsecurity-snippet annotation is not being validated at webhook admission time. This allows invalid ModSecurity rules to be deployed without any validation or error feedback.

What you expected to happen:

Invalid ModSecurity rules in the modsecurity-snippet annotation should be caught at admission time using the modsec-rules-check CLI tool. Users should receive clear feedback about validation failures, either as:

• A warning in non-strict mode (default): Invalid rules are logged as warnings but deployment proceeds
• A rejection in strict mode: Invalid rules cause the Ingress admission to be denied

NGINX Ingress controller version (exec into the pod and run /nginx-ingress-controller --version):

-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.14.3
  Build:         b4ab41015421ae27f3a96d73f013183b7e166735
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.27.1

-------------------------------------------------------------------------------

Kubernetes version (use kubectl version):

Client Version: v1.34.3
Kustomize Version: v5.7.1
Server Version: v1.33.6

Example Ingress with invalid modsecurity-snippet:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-modsec
  annotations:
    modsecurity-snippet: |
      SecRule INVALID SYNTAX HERE "id:100,phase:2,deny"
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

How to reproduce this issue:

1. Deploy ingress-nginx controller with ModSecurity enabled
2. Create an Ingress resource with an invalid modsecurity-snippet annotation (as shown above)
3. The Ingress is accepted without any validation or warning
4. No error message is provided to the user about the invalid rule syntax

Expected result: Admission webhook should validate the modsecurity-snippet and either:

• Emit a warning (in default mode), or
• Reject the Ingress (in strict mode)

Anything else we need to know:

This is a security and operational concern because:

• Invalid WAF rules may silently fail, leaving the application unprotected
• Debugging issues becomes harder when rules fail at runtime instead of deployment time
• Users don't receive any feedback about misconfigured security policies

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Gacko]

It is hard to validate these, as they are just snippets and the directives in there cannot by put in a structure, so we cannot validate the given values.

In the past we were loading the rendered NGINX configuration using nginx -t to uncover such issues before actually reloading the NGINX itself, but this led to the Ingress Nightmare CVEs.

Overall we recommend not using snippets at all and single annotations instead, even if this means we first need to implement them. But since ModSecurity is quite complex, we cannot implement each and every configuration option in a separate annotation.

Together with the fact that this project is going to get retired in a few weeks anyway, we will no longer implement such a change.

From a security perspective this is indeed an issue - in multi-tenant environments. But we do not recommend nor support running Ingress NGINX in multi-tenant environments, also because Ingress API itself has some flaws which do not properly support this.

With this I am closing this issue.