You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in the gvisor directory's readme, it is documented that unprivileged user namespace creation must be enabled1. to do that, it simply says to patch the user.max_user_namespaces sysctl.
then of course there is this issue which suggests that gvisor is possibly not compatible with the latest version(s) of talos?
finally, there are many issues related to setting up gvisor alongside cilium23 as well as docs explicitly to support this use case4. at first, i'm inclined to say this is out of scope for talos documentation; but on the other hand, if a user sets up cilium as documented in talos docs, gvisor doesn't work and from my experimentation it is far from trivial to reconfigure talos/kubernetes/cilium in such a way to handle gvisor resulting in major service disruption if done improperly
it might be a good idea to at least mention that, if a user configured cilium according to the docs, gvisor will not work and further configuration is needed, and care must be taken to do it properly
There's a bit of confusion on the term "user namespaces" here, there are two things:
by default, Talos doesn't allow non-root users to create new Linux namespaces, setting max_user_namespaces reverts this value; creating namespaces by non-root users very often leads to exploitable issues in the Linux kernel, specifically networking stack (as the creator will be effectively able to use any networking stuff in the new namespace)
user namespace as part of Linux namespaces which allows to remap users inside the namespace to the host, i.e. user ID 0 in the namespace is actually user ID 10000 on the host.
Any improvements to the documentation are very welcome as a PR to this or Talos repo!
okay i got it working actually, and the good news is most of my pains were mostly about tampering with my cni on an already-deployed cluster; so the updates i'm gonna propose for the docs will be minimal
in the gvisor directory's readme, it is documented that unprivileged user namespace creation must be enabled1. to do that, it simply says to patch the
user.max_user_namespaces
sysctl.but there are other docs that describe enabling user namespaces in talos/kubernetes: https://www.talos.dev/v1.9/kubernetes-guides/configuration/usernamespace/ - do we need to do this as well to accomodate gvisor?
then of course there is this issue which suggests that gvisor is possibly not compatible with the latest version(s) of talos?
finally, there are many issues related to setting up gvisor alongside cilium23 as well as docs explicitly to support this use case4. at first, i'm inclined to say this is out of scope for talos documentation; but on the other hand, if a user sets up cilium as documented in talos docs, gvisor doesn't work and from my experimentation it is far from trivial to reconfigure talos/kubernetes/cilium in such a way to handle gvisor resulting in major service disruption if done improperly
it might be a good idea to at least mention that, if a user configured cilium according to the docs, gvisor will not work and further configuration is needed, and care must be taken to do it properly
Footnotes
https://github.com/siderolabs/extensions/tree/main/container-runtime/gvisor#usage ↩
https://github.com/google/gvisor/issues/6998 ↩
https://github.com/cilium/cilium/issues/15626 ↩
https://docs.cilium.io/en/stable/network/kubernetes/kubeproxy-free/#socket-loadbalancer-bypass-in-pod-namespace ↩
The text was updated successfully, but these errors were encountered: