Skip to main content

Schema validation

Why run schema validation?

How do you know that your Kubernetes manifests are syntactically valid? Are you sure you don’t have any invalid data types? Are any mandatory fields missing? Most often, we only become aware of these misconfigurations at the worst time - when trying to deploy it.

How does it work?

There is no need to set up anything because every Kubernetes manifest that Datree scanned is also validated before the rules from the Centralized policy are executed.

If the manifest schema is invalid, the policy check will not be calculated. This way, you can ensure that all the files that are scanned by Datree are also valid Kubernetes files. Under the hood, we incorporated kubeconform with Datree to gain the schema validation capability.

[X]Failing schema validation[V]Passing schema validation

Changing the (default) schema version

To achieve optimal coverage, the version of the schema that is validated should be the same as your Kubernetes cluster. By default, the Kubernetes schema version is 1.19.0.


If you want to change the default version to match your Kubernetes cluster version, you can do it from the SETTINGS page:




Use case

This functionality is useful if you want to migrate to a new Kubernetes version. This way, you can set the version and start the process of evaluating which configurations must be changed to support the cluster upgrade.

Passing a different schema version to the CLI will override the global schema version that is passed from the SETTINGS page.

The CLI accepts the flag --schema-version, -s with a version number (as string):

$ datree test --schema-version "1.19.0" ~/.datree/k8s-demo.yaml

Overriding schemas location - CRD support

When the --schema-location parameter is not used, or set to "default", the CLI will be downloading schemas from kubernetes-json-schema. The CLI supports passing one, or multiple, schemas locations - HTTP(s) URLs, or local filesystem paths - in which case it will look for schema definitions in each of them, in order, stopping as soon as a matching file is found.

  • If the --schema-location value does not end with `.json`, the CLI will assume filenames / a file structure identical to kubernetes-json-schema.

  • If the --schema-location value ends with `.json` - the CLI assumes the value is a Go templated string that indicates how to search for JSON schemas.

  • The --schema-location value of "default" is an alias for https\://{{ .NormalizedKubernetesVersion }}-standalone{{ .StrictSuffix }}/{{ .ResourceKind }}{{ .KindSuffix }}.json. All of the following command lines are equivalent:

$ datree test fixtures/valid.yaml
$ datree test fixtures/valid.yaml --schema-location default
$ datree test fixtures/valid.yaml --schema-location '{{ .NormalizedKubernetesVersion }}-standalone{{ .StrictSuffix }}/{{ .ResourceKind }}{{ .KindSuffix }}.json'

Variables you can use with --schema-location

  • NormalizedKubernetesVersion - Kubernetes Version, prefixed by v

  • StrictSuffix - "-strict" or "" depending on whether validation is running in strict mode or not

  • ResourceKind - Kind of the Kubernetes Resource

  • ResourceAPIVersion - Version of API used for the resource - "v1" in "apiVersion:"

  • KindSuffix - suffix computed from apiVersion - for compatibility with Kubeval schema registries

How to pull your CRD's schemas to validate your manifests

  1. kubectl get crds -o yaml > crds_from_cluster.yaml

  2. python3 crds_from_cluster.yaml

  3. datree test *.yaml --schema-location default --schema-location '{{ .ResourceKind }}_{{ .ResourceAPIVersion }}.json'