-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
[FR]: implement fsUser option for securityContext #119507
Comments
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
/sig auth |
Totally agree. This is super important in order to handle such permission-sensitive services. Especially in a "minimum access" context where the container is not running as root or (worse?) the filesystem is read only. That is where this issue shows up the most. Workarounds with init containers are awkward and delay container startup time too. |
/close |
@stlaz: Closing this issue. In response to this:
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. |
Hello,
currently, it seems not to be possible to project secrets or configmaps to files with strict permissions to containers.
Some applications such as
sshd
require strict permissions on some files like~/.ssh/authorized_keys
, mainly, it requires that this file is owned by the user. For thesshd
there is an option to bypass this restrictionStrictModes
. However, there are different likepsql
that is able to use~/.pgpass
only with the correct permissions. Operators like cloudnative-pg create a secret that could be projected to~/.pgpass
, but owner cannot be set thuspsql
refuses to use it.I think it would be great, if
fsUser
option could be implemented or some other option that could be used to specify the owner of projected secrets/configmaps.The text was updated successfully, but these errors were encountered: