

Cgroups is not a really a security feature (from what I understand). It is about controlling process priority, hierarchy, and resources limiting (among other things).
With respect, I think you misunderstand what gvisor does and containerization in general. cgroups2 is the isolation mechanism used by most modern Linux containers, including docker and lxc both. It is similar to the jail concept in BSD, and loosely to chroot. It limits child process access to files, devices, memory, and is the basis for how subprocesses are secured against accessing host resources without the permission to do so.
Gvisor adds more layers of control over this system by adding a syscall control plane to prevent a container from accessing functions in the host’s kernel that might not be protected by cgroups2 policy. This lessens the security risk of the host running a cutting-edge or custom kernel with more predictable results, but it comes with caveats.
Gvisor is not a universally “better” option, especially for homelab, where environment workloads vary a lot. Gvisor comes with an IO performance penalty, incompatibility with selinux, and its very strength can prevent containers from accessing newer syscalls on a cutting edge host kernel.
My original comment was that ultimately, there is no blanket answer for “how secure is my virtualization stack”, because such a decision should be made on a case-by-case basis. And any choice made by a homelabber or anyone else should involve some understanding of the differences between each type.

I know this is the preferred way to do it now, but I sometimes worry that abstracting where things are configured in an is that configures everything in a file.
You used to only have to check two places to change a hostname.
Oldmanyellsatsky.jpg