Projected serviceAccountToken has mode of mounted file hardcoded to 0600

[alfredkrohmer]

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:

kubernetes/pkg/volume/projected/projected.go

Line 357 in cf76868

Mode: 0600,

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

[alfredkrohmer]

@kubernetes/sig-node-bugs

[k8s-ci-robot]

@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]

duplicate of #74565

/cc @mikedanese
/close

[k8s-ci-robot]

@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]

actually, leaving this open to track resolution

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

[k8s-ci-robot]

@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 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]

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]

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]

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]

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.

[willthames]

One point to note here is that setting the fsGroup to the gid of the pod is a commonly documented workaround for this issue. However, this gid is typically 0 by default, which doesn't seem ideal - but if you then set the gid of the pod with RunAsGroup, this solution no longer works (fsGroup seems to be dropped if RunAsGroup is set to the same value (presumably as it's no longer a supplemental group) and the token is then only owner-readable again)

Edit: fsGroup is only available in the pod security context, and I was trying to set it in the container security context.

[mikedanese]

Proposal to fix in kubernetes/enhancements#1598

[mikedanese]

Fixed by @zshihang in #89193