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.
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
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.18.0.
If you want to change the default version to match your Kubernetes cluster version, you can do it from the SETTINGS page:
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):
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 lookup for schema definitions in each of them, in order, stopping as soon as a matching file is found.