Hacker News Reader

Which is relevant because containerd most commonly runs as root, even in Kubernetes.

Actually, no. The root in container isn't actually uid 0 in host system if you setup things correctly. Linux user namespace can offset uid in a container by certain number. Effectively make uid 0 actually uid 60000, uid 1000 as uid 61000 and so on.

And in this case. If you escaped the container, you are literally nobody. All you allowed to read is public files that any user can read.

By the way. If you use rootless container, this is the default settings you will get. Since you don't have access to uid0 at first place.

You're correct in that uid 0 in the container is faked through userns, but you can easily bypass that with a privileged container or adding the CAP_ADMIN capability. Yes, you can disable creating privileged containers within Kubernetes, but that isn't something you can rely on. If the runtime is running as root, which it often is, you can also become real root within the container under these conditions.

>if you setup things correctly

Judging by the number of HOWTOs I see on GitHub and YouTube that tell you to check the Privileged box, this assumption isn't worth what you think it is.

It doesn't matter, the "root" user inside the container is still jailed and none of these tricks will allow that user to escape.

Reply on news.ycombinator.com