-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Run the virtiofsd container as non-root for config volumes #9609
Conversation
Let's rename the variable that holds the uid/gid of the virtiofsd privileged container. Signed-off-by: German Maglione <gmaglione@redhat.com>
Hi @germag. Thanks for your PR. I'm waiting for a kubevirt member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/cc @jcanocan |
/ok-to-test |
This profile will then be used to select with which privileges to run the virtiofsd container, based on the type of volume to be shared. Signed-off-by: German Maglione <gmaglione@redhat.com>
It runs the virtiofsd container as root only if the shared volume is _not_ a config volume. Signed-off-by: German Maglione <gmaglione@redhat.com>
Removes the test privileged namespace from virtiofs config volumes tests. Signed-off-by: German Maglione <gmaglione@redhat.com>
f383aa7
to
a23d66b
Compare
v2:
|
/retest-required |
@germag I have a question. IIUC, we are adding the noroot version but still keeping the root configuration option available. However, in the test now we are only testing noroot, do I understand the change correctly? |
Yes, but we only keep the root configuration for PVCs(*), and we keep testing those as root (*) Currently, we can share PVC as non-root, but the functionality is very limited. |
Thanks, do I need to do something? |
/retest-required |
Looking awesome for me! Please, add a release note. |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alicefr The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
privileged | ||
) | ||
|
||
func isRestricted(profile securityProfile) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like you could inline these two functions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean, replacing it by just profile == restricted
?, I did it first, but it felt less clear, specially in:
RunAsNonRoot: pointer.Bool(profile == restricted),
AllowPrivilegeEscalation: pointer.Bool(profile == privileged),
but I don't have a strong opinion about that
/hold cancel |
/retest-required |
@germag: The following tests failed, say
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. I understand the commands that are listed here. |
/retest-required |
What this PR does / why we need it:
Currently, we can share configuration volumes, such as ConfigMaps, Secrets, DownwardAPI and ServiceAccount using virtiofs, but the virtiofs container requires to be run as root.
Virtiofsd supports being run without privileges, so this PR to modify the container to run as the unprivileged user when sharing configuration volumes.
Reported-by: Javier Cano Cano jcanocan@redhat.com
Tested-by: Javier Cano Cano jcanocan@redhat.com
Related #7735
Release note: