Kubectl: Kubectl 'client' and 'server' validations work differently for env variable value format

[kofan]

What happened:

I have the following Pod template defined:

# "pod.yaml"

apiVersion: v1
kind: Pod
metadata:
  name: test-example
  namespace: test-namespace
spec:
  containers:
    - name: example
      image: busybox
      env:
        - name: FOO_TEST
          value: foo
        - name: BAR_TEST
          value: 1

---

Now, when I run the client validation

kubectl apply --dry-run=client --validate --filename="pod.yaml"

it succeeds:

pod/test-example created (dry run)

---

However, when I run the server validation

kubectl apply --dry-run=server --validate --filename="pod.yaml"

it fails:

Error from server (BadRequest): error when creating "pod.yaml": Pod in version "v1" cannot be handled as a Pod: v1.Pod.Spec: v1.PodSpec.Containers: []v1.Container: v1.Container.Name: Image: Env: []v1.EnvVar: v1.EnvVar.Value: ReadString: expects " or n, but found 1, error found in #10 byte of ...|,"value":1}],"image"|..., bigger context ...|_TEST","value":"foo"},{"name":"BAR_TEST","value":1}],"image":"busybox","name":"example"}]}}
|...

In other words, the server detects the fact that the value 1 should be quoted, while the client does not see the issue.

---

What you expected to happen:

The client validation should detect this kind of formatting issue and throw the same error as the server validation does.

How to reproduce it (as minimally and precisely as possible):

See the pod.yaml file I provided in the description and the kubectl commands to run.

---

Environment:

• Kubernetes client and server versions (use kubectl version):
  
  
  
  • Client Version: {Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T17:59:43Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"darwin/amd64"}
  
  
  • Server Version: {Major:"1", Minor:"19", GitVersion:"v1.19.7+IKS", GitCommit:"7801b1132095b75d52104472f21cc27406e00724", GitTreeState:"clean", BuildDate:"2021-01-15T06:20:15Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
  
  

• Cloud provider or hardware configuration: IBM Cloud
• OS (e.g: cat /etc/os-release): Mac OS X 10.15.6

[eddiezane]

This may already be tracked in a few places.

Difference is that server uses a Go struct and kubectl uses the OpenAPI schema that is published per resource.

I think the action is to switch to a vendored api?

/assign @soltysh

cc @apelisse

[apelisse]

I think the action is to switch to a vendored api?

Nooooooooo :-)

We have server-side validation and client-side validation. I'm much more concerned about things that are rejected client-side and accepted server-side than the opposite. The server should be authoritative. There are a few projects that we're interested in doing to improve client-side (and server-side) validation, including: validation ratcheting (to fix invalid server-side validation), declarative validation (to include some of the validation in the openapi spec), using a better validator on the client.

[kofan]

Yes, it is totally fine and reasonable that the server throws a validation error that the client could not detect. Like, for example, duplicated resource names, or modification of immutable fields.
However, validating the format of environment variable values looks like a simple task that the client can do without a problem...

[apelisse]

Yeah, I agree with that, I don't have a lot of time to look into the specific details, but I'm happy to help someone get started and move forward with that issue if there's interest.

[eddiezane]

/triage accepted
/priority backlog

Client validation can't be weaker than the server.

This might make 1.21.

[eddiezane]

/assign @KnVerey