UPDATE: This was due to my mistake and I don't have access to close this issue. Please consider the issue invalid.
When running kubeconform v0.7.0 against one of our Helm charts targeting Kubernetes v1.32.0, I encountered a misleading validation error for an HTTPProxy resource (a custom resource from Project Contour):
/my/chart/path/my-chart/my-chart-helm-template_k8s_1.32.0.yaml: HTTPProxy failed validation: my-chart-ingress could not find schema for HTTPProxy
At first, this suggested that the CRD schema could not be found. However, I am passing the correct CRD schema file (httpproxy-projectcontour-v1.json) to kubeconform.
After debugging by running kubeconform locally from source, I found that the root cause is not a missing CRD, but a validation error in my CRD JSON file. The error trace shows:
"file:///my/local/path/k8s-schemas/crds/v1.32.0-standalone-strict/httpproxy-projectcontour-v1.json#" is not valid against metaschema: jsonschema validation failed with 'https://json-schema.org/draft/2020-12/schema#'
- at '': allOf failed
- at '/properties/spec': allOf failed
- at '/properties/spec': validation failed
- at '/properties/spec/properties/routes': allOf failed
- at '/properties/spec/properties/routes/items': allOf failed
- at '/properties/spec/properties/routes/items/properties/services': allOf failed
- at '/properties/spec/properties/routes/items/properties/services/items': allOf failed
- at '/properties/spec/properties/routes/items/properties/services/items/properties/port': allOf failed
- at '/properties/spec/properties/routes/items/properties/services/items/properties/port/exclusiveMaximum': got boolean, want number
- at '/properties/spec/properties/tcpproxy': allOf failed
- at '/properties/spec/properties/tcpproxy/properties/services': allOf failed
- at '/properties/spec/properties/tcpproxy/properties/services/items': allOf failed
- at '/properties/spec/properties/tcpproxy/properties/services/items/properties/port': allOf failed
- at '/properties/spec/properties/tcpproxy/properties/services/items/properties/port/exclusiveMaximum': got boolean, want number
This indicates that kubeconform is validating CRDs against JSON Schema draft/2020-12.
But according to the official Kubernetes documentation (CustomResourceDefinition validation), Kubernetes uses OpenAPI v3.0 (which is based on JSON Schema draft-4) for schema validation, and NOT OpenAPI v3.1 (based on draft/2020-12). Kubernetes has no plans to switch validation to OpenAPI v3.1 (draft/2020-12).
The fields exclusiveMaximum and exclusiveMinimum were previously a boolean until OpenAPI schema version 3.0 (based on json schema version Draft-4). But from the OpenAPI schema version 3.1 onwards (based on json schema version 2020-12), the field's type is changed to an integer. But since Kubernetes is still using the older JSON schema version, kubeconform should also validate the resource templates against the older JSON schema version instead of the latest one.
Problem:
Because kubeconform is using the wrong JSON Schema version (draft/2020-12), valid CRDs/resources based on OpenAPI v3.0 fail validation with misleading error messages.
Expected behavior:
Kubeconform should validate CRDs against JSON Schema draft-4 (to align with Kubernetes’ OpenAPI v3.0 validation), not draft/2020-12.
Steps to reproduce:
Install kubeconform 0.7.0.Generate Helm templates targeting Kubernetes v1.32.0 that include a Project Contour HTTPProxy resource (CRD, httpproxy-projectcontour-v1.json)Run kubeconform with the path to the CRD schema file (httpproxy-projectcontour-v1.json)Observe the misleading “could not find schema” error.
Environment:
kubeconform version: 0.7.0
Note: The issue was not found with kubeconform 0.4.12
Kubernetes version: 1.29.0, 1.30.0, 1.31.0, 1.32.0, 1.33.0
Schema source: httpproxy-projectcontour-v1.json (from Project Contour CRDs)
Proposed fix:
Ensure kubeconform validates CRDs against JSON Schema draft-4 (OpenAPI v3.0), not draft/2020-12.
What do I think is the issue?
Kubeconform internally uses the jsonschema library to do the JSON schema validation, but jsonschema by default uses the latest version of JSON schema to validate the JSON files, which should not be in this case. When creating the jsonschema compiler in validator.go, instead of using jsonschema's NewCompiler() to create the Compiler object, a custom Compiler needs to be created with a custom Roots that uses a custom Loader.
UPDATE: This was due to my mistake and I don't have access to close this issue. Please consider the issue invalid.
When running kubeconform v0.7.0 against one of our Helm charts targeting Kubernetes v1.32.0, I encountered a misleading validation error for an HTTPProxy resource (a custom resource from Project Contour):/my/chart/path/my-chart/my-chart-helm-template_k8s_1.32.0.yaml: HTTPProxy failed validation: my-chart-ingress could not find schema for HTTPProxyAt first, this suggested that the CRD schema could not be found. However, I am passing the correct CRD schema file (httpproxy-projectcontour-v1.json) to kubeconform.After debugging by running kubeconform locally from source, I found that the root cause is not a missing CRD, but a validation error in my CRD JSON file. The error trace shows:This indicates that kubeconform is validating CRDs against JSON Schema draft/2020-12.But according to the official Kubernetes documentation (CustomResourceDefinition validation), Kubernetes uses OpenAPI v3.0 (which is based on JSON Schema draft-4) for schema validation, and NOT OpenAPI v3.1 (based on draft/2020-12). Kubernetes has no plans to switch validation to OpenAPI v3.1 (draft/2020-12).The fields exclusiveMaximum and exclusiveMinimum were previously a boolean until OpenAPI schema version 3.0 (based on json schema version Draft-4). But from the OpenAPI schema version 3.1 onwards (based on json schema version 2020-12), the field's type is changed to an integer. But since Kubernetes is still using the older JSON schema version, kubeconform should also validate the resource templates against the older JSON schema version instead of the latest one.Problem:Because kubeconform is using the wrong JSON Schema version (draft/2020-12), valid CRDs/resources based on OpenAPI v3.0 fail validation with misleading error messages.
Expected behavior:Kubeconform should validate CRDs against JSON Schema draft-4 (to align with Kubernetes’ OpenAPI v3.0 validation), not draft/2020-12.
Steps to reproduce:Install kubeconform 0.7.0.Generate Helm templates targeting Kubernetes v1.32.0 that include a Project Contour HTTPProxy resource (CRD, httpproxy-projectcontour-v1.json)Run kubeconform with the path to the CRD schema file (httpproxy-projectcontour-v1.json)Observe the misleading “could not find schema” error.Environment:kubeconform version: 0.7.0Note: The issue was not found with kubeconform 0.4.12
Kubernetes version: 1.29.0, 1.30.0, 1.31.0, 1.32.0, 1.33.0Schema source: httpproxy-projectcontour-v1.json (from Project Contour CRDs)Proposed fix:Ensure kubeconform validates CRDs against JSON Schema draft-4 (OpenAPI v3.0), not draft/2020-12.
What do I think is the issue?Kubeconform internally uses the jsonschema library to do the JSON schema validation, but jsonschema by default uses the latest version of JSON schema to validate the JSON files, which should not be in this case. When creating the jsonschema compiler in validator.go, instead of using jsonschema's NewCompiler() to create the Compiler object, a custom Compiler needs to be created with a custom Roots that uses a custom Loader.