Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

@soltysh This needs another case in the secrets e2e

@soltysh I think that new case case be, create different files with different modes and use the mount tester binary to check them. You can only check one file's mode with the current mount tester so it will probably 1 case per non-standard mode

Unless there is a good reason to rush this, I'd like to put a hold on this
till I (we?) understand #7925 better.
For one thing, I'm not sure whether the permissions belong on the Secret or
the SecretVolumeSource.

On Thu, May 7, 2015 at 3:09 PM, Paul Morie notifications@github.com wrote:

@soltysh https://github.com/soltysh I think that new case case be,
create different files with different modes and use the mount tester binary
to check them. You can only check one file's mode with the current mount
tester so it will probably 1 case per non-standard mode

—
Reply to this email directly or view it on GitHub
#7908 (comment)
.

@erictune

For one thing, I'm not sure whether the permissions belong on the Secret or
the SecretVolumeSource.

I'm actually thinking now that #7925 is what we ought to be talking about. Once we have security and volumes sorted there shouldn't be any need to control permissions -- secrets in volumes should always be 0400, owned by the uid in the pod's security context, and have the selinux context set correctly.

That was my first take in resolving #4789, just to set by default 0400 on mounted secrets. Still that kind of action generates risk that since we mount those as root, only root will have access to it. I then started chatting with @pmorie about that and we came up with this solution. I'll then wait for #7925 and its output.

Not sure if this is still active? If it isn't, it can be closed.

At any rate, I don't think there will be time to complete review of this prior to the pre-v1 code freeze.

I'm closing this until this gets sorted out, but everything seems that it'll be done differently.