validation false positives if input is stdin

[jkroepke]

Hi,

i'm running kubeval to validate my helm manifests.

While I'm testing with it I get errors with binaryData property via stdin.

Here is my configmap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: init
  labels:
    app.kubernetes.io/component: keycloak
binaryData:
  mock-data.xls: "< ~200000 chars >"

Running kubeval --strict init.yaml works fine while cat init.yaml | kubeval --strict results into an error:

The document stdin contains an invalid ConfigMap
---> binaryData: Invalid type. Expected: object, given: null

[yannh]

Hi @jkroepke , could you maybe share a file to reproduce this? Thanks!

[scovl]

@jkroepke First, it's important to keep in mind that ConfigMaps are intended to store configuration data and not large binary files. The Kubernetes API makes no guarantees to preserve the integrity of binary data in ConfigMaps, and it is possible for data to change or become corrupted during transmission.

Also, representing binary data as a base64-encoded string can result in a large amount of serialized data and therefore consume a lot of memory. Therefore, instead of storing binary files in ConfigMaps, it is recommended to use other data storage mechanisms such as Kubernetes PersistentVolume to store large binary files.

This error indicates that the content of binaryData is in an invalid format. According to the Kubernetes documentation, the binaryData attribute expects an object with keys and values, where the keys are filenames and the values are the base64-encoded binary data. In this case, the error indicates that the value of binaryData is null, which is not valid. Make sure you are providing the correct binary data for the attribute and that it is correctly base64 encoded.

So it's not a bug (luckily kubeval is more correct than kubectl).

@garethr You can close the issue, it's not a bug buddy

[jkroepke]

Hey @lobocode,

thanks for your response! This bug is near 3 year old. At this time, we stored a excel sheet in that config map.

In any ways, we all the down sides you mentioned, the ConfigMap was valid and could be successfully mounted in a kubernetes cluster. The excel sheet could be read by the software without any additional issues. The config map was appled by helm.

From pure technical point of view, this is a valid ConfigMap and Kubernetes support such scenario up to 1MB. It should not matter how stupid this procedure this, but building an image each time results into more downsides as put them in the config map.

So it's not a bug (luckily kubeval is more correct than kubectl).

This statement is not true. In general, kubeval accept this configmap kubeval --strict init.yaml, except the input was coming from stdin. There is an error in kubeval for reading a large amount of data.

Anyways, after 3 year, I'm not longer able to reproduce the error...

[scovl]

@jkroepke I prefer to follow the best practices and guidelines outlined in official documentation, rather than just exploring what can be done. Take, for instance, the existence of a document called the 12 factors for working with containers. This is because many individuals are mindful of following the recommended methodologies. I don't view the aforementioned output as a bug. I consider it a normal occurrence

[jkroepke]

@lobocode It fine to follow best practices. But a validator should not follow best-pratices. A validator should check if the manifest is valid. Additional best practice check should be an opt-in or opt-out, but should always result in a warning by default.

But best practices are not must, if the maintaince is too high and Kubernetes offer this alternative solution, its okay to use it.