Description
What would you like to be added:
Currently, you can set secret file permissions, but not ownership: (see the "Secret files permissions" section)
https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets
It would be good to add a defaultOwner
, and possible defaultGroup
field that would allow setting the default ownership of the secret files.
Why is this needed:
It is possible that there is more than one process running in a container, each running as a different user. (think processA
running as userA
and processB
running as userB
). processA
might need to use secretA
and processB
to use secretB
.
To make the secrets usable today, secretA
and secretB
would need to be world-readable, because there is no way to set ownership on them. This is undesirable from the security standpoint, as processA
could read secretB
and vice versa.
Activity
maxneaga commentedon Aug 7, 2019
/sig auth
tallclair commentedon Aug 7, 2019
/cc @jingxu97
liggitt commentedon Aug 7, 2019
see also #57923 (specifically #57923 (comment))
liggitt commentedon Aug 7, 2019
I think this is what the fsGroup setting was intended to accomodateedit: misread the description as multiple containers running as different users wanting access to the same secret.
this is asking for a way to have multiple processes in a single container running as different users not have access to portions of the same secret?
maxneaga commentedon Aug 7, 2019
Correct, multiple processes in a single container running as different users not have access to another or portions of the same secret.
tallclair commentedon Aug 7, 2019
This does not sound like a very common use case. Different processes running under different users are typically separated to different containers.
There are a handful of ways you could implement a custom solution within a container, but this doesn't sound like a use case we're likely to support in Kubernetes.
/priority awaiting-more-evidence
maxneaga commentedon Aug 12, 2019
Let's say there is only one process running in the container, and the container's security context has
Currently, the secret file would still be created with
root
as the owner. Unless the file is world-readable, the main container process will not be able to read it. So in this scenario (which is not uncommon I would guess), there is little to no use for thedefaultMode
. Either the secret file needs to be created with the owner ofrunAsUser
or you should be able to explicitly set the owner of the secret file.138 remaining items