Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Projected serviceAccountToken has mode of mounted file hardcoded to 0600 #82573

Open
devkid opened this issue Sep 11, 2019 · 11 comments

Comments

@devkid
Copy link

commented Sep 11, 2019

What happened:

Mounting projected serviceAccountTokens into a container always sets the mode of the mounted token files to 0600. This is hardcoded in the source code:

What you expected to happen:

The file mode should equal the defaultMode given in the projected map.

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

Create a pod with a projected serviceAccountToken with any defaultMode set. Observe that the file mode of the file is always 0600.

Environment:

  • Kubernetes version (use kubectl version): latest master
@devkid

This comment has been minimized.

Copy link
Author

commented Sep 11, 2019

@kubernetes/sig-node-bugs

@k8s-ci-robot k8s-ci-robot added sig/node and removed needs-sig labels Sep 11, 2019

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@devkid: Reiterating the mentions to trigger a notification:
@kubernetes/sig-node-bugs

In response to this:

@kubernetes/sig-node-bugs

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@liggitt

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

duplicate of #74565

/cc @mikedanese
/close

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@liggitt: Closing this issue.

In response to this:

duplicate of #74565

/cc @mikedanese
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@liggitt

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

actually, leaving this open to track resolution

/remove-sig node
/sig auth
/assign @mikedanese
/reopen

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@liggitt: Reopened this issue.

In response to this:

actually, leaving this open to track resolution

/remove-sig node
/sig auth
/assign @mikedanese
/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@mikedanese

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

This might be a docs issue, or the webhook could work around this by adding supplemental groups. I'm not sure if that's particularly desirable.

cc @micahhausler

@micahhausler

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

Yea, adding supplemental groups from the webhook is probably not the route we want to go, since it's hard to determine which GID is correct. We'll update our docs on that workaround, but having the mode be set by defaultMode is the desired behavior

@mikedanese

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

deafultMode defaults to world readable. The current behavior was intentional. I would really like if the world bit was never set on these tokens. This is something that I was hoping to fix with the second iteration of tokens. Coincidentally, the security audit pointed this issue out: #81116

@liggitt

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

Would you agree that requiring changes to pod specs in order to replace the secret-based token with the projected one by default doesn't seem tenable? If we can't require pod spec changes, and the pod spec doesn't contain enough info to confidently use gid / fsGroup / supplementalGroups, I don't see great options other than preserving the secret-based behavior.

What are the actual risks of injecting a token that is group or world-readable into a pod?

@mikedanese

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

I'd like to pursue the avenue of setting better file ownership of TokenVolumeProjections which would be preferable as it offers better security to users that are running as non-root transparently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.