helm: Json Schema validation is not friendly when used with chart dependencies

Currently, if you use a json schema with Chart.yaml dependencies, you will run into - (root): Additional property global is not allowed.

This can be reproduced with a Chart.yaml like

apiVersion: v2
name: istio-gateway
version: 0.0.1
appVersion: 1.12.0
description: "This Helm chart is an installation of istio-gateway, with additional components."
home: https://istio.io/latest/docs/setup/install/helm/

dependencies:
- name: gateway
  version: 1.12.0
  repository: https://istio-release.storage.googleapis.com/charts

Then we will see:

$ helm template .
Error: values don't meet the specifications of the schema(s) in the following chart(s):
gateway:
- (root): Additional property global is not allowed

This is because the helm chart does not define global in the json schema. This seems reasonable from the chart point of view - when used as-is, global is not a valid.

Its not clear how either a chart author should accommodate for this, or how a a chart consumer should account for this.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 17
Comments: 17 (6 by maintainers)

Commits related to this issue

allow additional properties for use as a subchart without this change, this chart cannot be used a subchart as of 2022-01-14. because helm adds a "global" property to the subchart. cf https://githu... — committed to bowtie-ltsa/charts by bowtie-ltsa 2 years ago
istio ingress removed because of active issue https://github.com/istio/istio/issues/23003 https://github.com/helm/helm/issues/10392 — committed to manu-mishra/k8 by deleted user 2 years ago
Helm: allow unknown fields to workaround helm limitations Helm schema is completely broken for strict field validation and the maintainers have decided they won't change it. See https://github.com/he... — committed to howardjohn/istio by howardjohn a year ago

Most upvoted comments

This is still an issue, would be great to have open

howardjohn on Sep 3, 2022

I just took a look at Bitnami’s way of handling this. Bitnami’s Apache chart They are omitting to set the "additionalProperties" property in the values.schema.json, which defaults to "additionalProperties": true where in the Istio gateway chart it is set as: "additionalProperties": false (Code reference).

I just tested the istio gateway chart as a subchart where it works by omitting "additionalProperties" or setting "additionalProperties": true in values.schema.json in the gateway chart.

This means that it is possible to supply any additional properties (whether it is .global or .gateway-subchart-name.whatever), which I don’t know whether is a benefit or a disbenefit. If "additionalProperties": true is set, Helm only verifies that any overriding property value set by people is following the definitions defined in values.schema.json (defined by the chart owner). So people won’t be able to set an array where the property value should be a string.

I don’t know whether a chart owner should be strict or be lenient in regards of a user supplying undefined properties in a subchart.

nc-ruth on Dec 23, 2021

As @nc-ruth wrote, this is by design. The JSON schema spec. defines how a JSON schema Interpreter - such as the one Helm is using - should handle additionalProperties. Helm simply sticks to the spec. here.

The problem seems to be that the authors of your chart - in Ops case the Istio chart - have defined the additionalProperties setting in their chart, essentially telling Helm - or really any JSON schema validator - that it’s not allowed to have any additional properties defines besides those defined in their JSON schema. You should discuss the reasoning behind that decission with the chart authors.

A temporary workaround could be to disable chart validation when running Helm against a chart you don’t control which has that property defined. That said it’s arguably better to create a fork of such a chart and remove that additionalProperties since you probably want to keep chart validation.

omniproc on Dec 28, 2022

@Divyakhatnar that is istio specific, but only global has been fixed/mitigated - the rest are legitimately invalid keys that are not used in the chart.

howardjohn on May 4, 2022

We have run into this issue as well, but I guess it is both expected and surprising depending on how you look at it. It seems that when you reference a subchart, the global section from the parent chart is implicitly injected into the subchart’s values.yaml file for validation. After all, the global section is shared among all subcharts.

Furthermore, if you reference a subchart (even a library chart), an implicit entry is made into the parent chart’s values.yaml file for the subchart’s configuration, such as:

global:
  ...

some: "config"

subchart: # This is implicitly injected
  child: "Config"

So, if you have not taken into account this implicit sections in your values.yaml file, and set "additionalProperties": false in the root of values.schema.yaml, you will run into similar trouble. In this case where we reference a subchart, it is easily handled since we are the author’s of the parent chart and can change the schema.

However, in the former case, I guess it is just a matter of explicitly permitting the global keyword in your schema files if you really wish to set "additionalProperties": false. I am not sure that I would say this is necessarily Helm’s issue, but rather improper use of values.schema.json files by chart authors being a little too strict. I cannot come up with a case where including a subchart forces any other section than global to be injected, so it seems like a fairly general case to cover. When not permitting the global keyword, your schema file is essentially stating that global values are explicitly not permitted - and I don’t know why you would want to enforce that.

You could say this is just a quirk of writing JSON schemas for Helm?

Xitric on Apr 7, 2022