KEP-127: update based on current PSS integration approach #4691
Conversation
haircommander
commented
Jun 4, 2024
haircommander
commented
- One-line PR description:
- Issue link: Support User Namespaces in pods #127
- Other comments:
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
size/M
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haircommander, mrunalp 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 |
k8s-ci-robot
added
the
approved
|
@liggitt ptal |
|
FYI: here's the implementation kubernetes/kubernetes#125198 |
|
|
||
| The validation for capabilities can be relaxed in a baseline pod because capabilities | ||
| are user namespaced in the linux kernel, and any pod does not have a seccomp profile (as baseline | ||
| pods are not required to) has access to the `unshare` syscall, allowing a user to create a user |
There was a problem hiding this comment.
any pod does not have a seccomp profile (as baseline pods are not required to)
how does this interact with https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2413-seccomp-by-default where a pod that does not opt into a seccomp profile gets one applied at the kubelet level?
does this ability to add arbitrary capabilities undo protections a cluster administrator put in place by defaulting seccomp on at the node level?
There was a problem hiding this comment.
Since PSA doesn't require RuntimeDefault in baseline, even if RuntimeDefault is on (which needs a kubelet flag to enable) a sufficiently knowledgeable user can just set it to Unconfined and still be in baseline.
There was a problem hiding this comment.
a sufficiently knowledgeable user can just set it to Unconfined and still be in baseline
baseline disallows explicitly setting to Unconfined
There was a problem hiding this comment.
ah I see, I misunderstood that section. okay, so if kubelet sets SeccompDefault, then this would technically increase the capabilities of a container. That said, I still think user namespaced capabilities are safer than not user namespaced capabilities. summoning @giuseppe who can probably advocate for that better than me
There was a problem hiding this comment.
It's odd that we allow nil or unset seccompProfile but not Unconfined. Is there a difference?
There was a problem hiding this comment.
Unconfined explicitly opts out of seccomp
nil / unset allows https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2413-seccomp-by-default to take effect
There was a problem hiding this comment.
Ah fair point. Thanks! But what is the intent here? Seem to me to be to not allow Unconfined right? So should we only allow nil when --seccomp-default is set to RuntimeDefault?
|
|
||
| The validation for capabilities can be relaxed in a baseline pod because capabilities | ||
| are user namespaced in the linux kernel, and any pod does not have a seccomp profile (as baseline | ||
| pods are not required to) has access to the `unshare` syscall, allowing a user to create a user |
There was a problem hiding this comment.
cc @tallclair @vinayakankugoyal for visibility / ack on the capabilities implications of pods without a seccomp profile that are in a user namespace
| nodes will honor user namespaces is on the cluster admin, though. | ||
|
|
||
| The relaxation in detail means, that if user namespaces are enabled, then the following fields | ||
| will be accessible to pods in a restricted namespace: | ||
|
|
||
| - `spec.securityContext.runAsNonRoot` |
There was a problem hiding this comment.
are you saying that when userns is enabled
runAsNonRoot can be set to false and runAsUser/runAsGroup can be set to 0?
If so then lets just say it like that? WDYT?
There was a problem hiding this comment.
thanks I reworded to be a bit less verbose, PTAL @vinayakankugoyal
haircommander
force-pushed
the
userns-pss-update
branch
from
c80f21b
to
9e8a51e
Compare
| Concretely, the "relaxation" means if a pod has `hostUsers` set to false, then the fields `runAsNonRoot` can be set to false and | ||
| `runAsUser` and `runAsGroup` can be set to any value for any `securityContext` in the pod (pod, container, initContainer, ephemeralContainer). | ||
|
|
||
| Further, validation will also be relaxed for pods with `hostUsers` to false in a baseline namespace, where the `capabilities` field can be set for |
There was a problem hiding this comment.
would it make sense to clarify that the relaxation applies to capabilities.add field and that any capability can be added in the case of non hostUser pods where as hostUser pods are allowed to add a certain set of capabilities.
There was a problem hiding this comment.
thanks! updated
Signed-off-by: Peter Hunt <[email protected]>
haircommander
force-pushed
the
userns-pss-update
branch
from
9e8a51e
to
2ec92c6
Compare
|
/lgtm |
k8s-ci-robot
added
the
lgtm
