In a CRD's schema, invalid schemas for array elements are accepted

[MikeSpreitzer]

What happened?

I accidentally wrote an invalid OpenAPI v3.0 schema for the elements of an array in a CRD's schema. kubectl create --validate=strict accepted my CRD definition without complaint, and silently discarded my invalid schema property. I have attached two files that demonstrate the problem. test1.yaml.txt gets rejected, while test2.yaml.txt is accepted but the {propertyNames: {pattern: foo}} gets silently transformed to {}.

test2.yaml.txt

test1.yaml.txt

What did you expect to happen?

I expected my schema to be implemented or rejected.

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

Shown above.

Anything else we need to know?

No response

Kubernetes version

```console $ kubectl version Client Version: v1.29.2 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.29.2 ```

Cloud provider

none

OS version

MacOS 15.0.1 container runtime is docker in Rancher Desktop. Inside the VM guest, `/etc/os-release` says: ``` NAME="Alpine Linux" ID=alpine VERSION_ID=3.20.3 PRETTY_NAME="Alpine Linux v3.20" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues" BUILD_ID="v0.2.39.rd4" VARIANT_ID="rd" ```

Install tools

kind v0.22.0

Container runtime (CRI) and version (if applicable)

docker in Rancher Desktop; client v27.2.1-rd; server engine 26.1.5, containerd v1.7.17, runc 1.1.14, docker-init 0.19.0

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

[liggitt]

/sig api-machinery

Server side field validation should be catching / complaining about this

[chengjoey]

Possibly related to issue #125885 pr: #125907

when use kubectl with option validate=strict, Strict validation should be performed using yaml.NewYAMLOrJSONDecoder(v.Reader, 4096, yaml.WithStrict())

Edit

yaml.UnmarshalStrict

[liggitt]

ah, right... anything that implements custom JSON unmarshaling cannot honor strict decoding, because the Go JSON decoding interface doesn't give any way to propagate per-operation decoding options to UnmarshalJSON

[liggitt]

this is also reported upstream in https://github.com/golang/go/issues/41144

this could be addressed by the proposed json v2 (https://github.com/golang/go/discussions/63397) in future go versions that allows plumbing options to type-specified unmarshaling (search for "Type-specified customization" on that page)

[liggitt]

cc @jpbetz @deads2k for visibility /triage accepted /priority important-longterm

[jpbetz]

cc @Jefftree