Secret defaultMode / mode not respected initially

[wernight]

Kubernetes version:

Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.7", GitCommit:"a2cba278cba1f6881bb0a7704d9cac6f
ca6ed435", GitTreeState:"clean", BuildDate:"2016-09-12T23:15:30Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"li
nux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"a16c0a7f71a6f93c7e0f222d961f4675
cd97a46b", GitTreeState:"clean", BuildDate:"2016-09-26T18:10:32Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"li
nux/amd64"}

Environment:

• Cloud provider or hardware configuration: GKE

What happened:
Changes the permission to 420 instead of 256, so -rw-r--r-- instead of -r-----.

What you expected to happen:
Should preserve 0700 (256).

How to reproduce it (as minimally and precisely as possible):
Following Secret files permissions, setting defaultMode (without setting fsGroup) in a Yaml like:

volumes:
  - name: foo
    secret:
      - secretName: mysecret
      - defaultMode: 0400

And doing a kubectl apply -f my_file.yml.

Note: It's a Deployment with normally only the container image that is changing.

Anything else do we need to know:
Editing the pod and changing the defaultMode: 0700 (again) works.

Related to #4789

[wernight]

Upgraded kubectl:

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"a16c0a7f71a6f93c7e0f222d961f4675
cd97a46b", GitTreeState:"clean", BuildDate:"2016-09-26T18:16:57Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"li
nux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"a16c0a7f71a6f93c7e0f222d961f4675
cd97a46b", GitTreeState:"clean", BuildDate:"2016-09-26T18:10:32Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"li
nux/amd64"}

Seems to fix the bug.

[rata]

@wernight yes, you need kubectl from 1.4 release too. Glad it works that way! :-)

[pwittrock]

@saad-ali @yujuhong This either of you?

[rata]

@pwittrock @wernight reported that upgrading kubectl to 1.4 did the trick (and it won't work with kubectl 1.3.x as the feature is not there, so the field is probably not sent by kubectl). He reported it here: #4789

@wernight can you confirm this should be closed too?

[pwittrock]

Ah, this is probably due to round tripping the objects in kubectl so it wipes out values it doesn't know about

[rata]

@pwittrock yeap, this is not expected to work with kubectl 1.3 and the report says it was using that. So quite confident that was the issue :-)

[wernight]

Should close, no? I expected a validation error but that may be for the future.