TestIngressRecoverFromInvalidPath is failing when changing router flavor to expressions

[pmalek]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

After fixing the router flavor setting in integration tests #5112 (which we didn't set properly when we originally changed the setting in #4934) TestIngressRecoverFromInvalidPath is failing by accepting the supposedly invalid regex

kubernetes-ingress-controller/test/integration/ingress_test.go

Line 868 in 513db87

Path: `/~^^/*$`, // invalid regex

which shouldn't be accepted.

Expected Behavior

No response

Steps To Reproduce

No response

Kong Ingress Controller version

No response

Kubernetes version

No response

Anything else?

No response

[randmonkey]

This ingress will generate a valid expression when expression router enabled:

((http.path == "/bar") || (http.path ^= "/bar/")) || (http.path ~ "^^/*$")

expression router will NOT validate regexes on the RHS of predicates and reject invalid regexes. Instead, NO strings could satisfy the predicate if regex is invalid. So the method to test recovery from invalid configurations could be:

• Create some k8s resources that will generate invalid config for both router flavors
• Skip this case when expression router enabled

[pmalek]

I was trying to come up with some examples of configurations which would fail to get applied and I came up with a plugin that references a non existing Secret

apiVersion: v1
kind: Service
metadata:
  labels:
    app: httpbin
  name: httpbin-deployment
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: httpbin
  type: ClusterIP
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: key-auth-1
plugin: key-auth
configFrom:
  secretKeyRef:
    name: secret1
    key: key1
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-ingress
  annotations:
    konghq.com/strip-path: "true"
    konghq.com/plugins: key-auth-1
spec:
  ingressClassName: kong
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: httpbin-deployment
            port:
              number: 80

Would that make sense? It's not blocked by CEL expressions or the admission webhook so this should fit this use case. We can then check in the test that the plugin wasn't applied.

OTOH this does allow the configuration to be applied, without only the broken plugin.

[randmonkey]

Sounds good, I will add this case (while we should be able to validate this after #5190).