What happened?

@robscott pointed out to me that a CEL x-kubernetes-validations rule in a CRD was hitting the estimated cost limit when performing a simple "string has prefix" check on an en enum field.

Putting a maxLength limit in the OpenAPI of the enum string field fixed the problem, but having to add a limit like this is counter-intuitive and unnecessary, since the allowed enum values already make the max allowed length obvious.

What did you expect to happen?

The apiserver automatically computes the max length of an enum as the length of the longest allowed enum value.

I believe we already refuse evaluate CEL rules on values that fail OpenAPI value validation, since we rely in the value validations to establish all length limits.

How can we reproduce it (as minimally and precisely as possible)?

I haven't tested it locally, but something like this should work (given enough nested arrays):

openAPIV3Schema:
  type: object
  properties:
    spec:
      type: array
      items:
        type: array
        nested:
          type: string
          enum: ["low", "medium", "high"]
          x-kubernetes-validations:
            - rule: 'self.matches("Prefix")'

Anything else we need to know?

As a workaround, one can manually set maxLength on the string enum, e.g.:

          type: string
          maxLength: 6
          enum: ["low", "medium", "high"]
          x-kubernetes-validations:
            - rule: 'self.matches("Prefix")'

Kubernetes version

1.25+

Cloud provider

All

OS version

No response

Install tools

No response

Container runtime (CRI) and version (if applicable)

No response

Related plugins (CNI, CSI, ...) and versions (if applicable)

No response