Kubernetes namespaces with RBAC: sufficient for tenant isolation in a public environment?

Question

Initially namespaces have been created to enable logical partitioning of a single Kubernetes cluster in order to prevent naming conflicts. Over time, this changed. While this article from 2016 sais

Any user or resource in a Kubernetes cluster may access any other resource in the cluster regardless of namespace. So, if you need to protect or isolate resources, the ultimate namespace is a separate Kubernetes cluster [...]

With RBAC it's now possible to set permissions on a specific namespace and thus restrict authenticated users to specific namespaces and their resources.

So, if I get this right, the quote from above is outdated. With RBAC in place it's possible to make sure a user or resource may only access stuff in their own namespace. Is that correct? I struggle to find recent documentation that explicitly sais that it's fine use namespaces (with RBAC) to seperate tenants from accessing each others stuff. Does anyone use namespaces and RBAC to seperate (unfriendly) tenants? Is there any clear statement about this from the CNCF?

If so, purely from a security perspective, what level of isolation are we talking about here? Clearly, the cluster IP would be accessible to all tenants and even with quotas in place I can imagine simple DOS attacks that might break a single cluster. Simple RBAC misconficutions might leak data between tenants and of course there's also the risk of implementation error and future exploitation. But if we consider those things "acceptable", are namespaces really a good tool for tenant isolation?

Answer 1

There's an active SIG devoted to multitenancy so I have a hard time believing that nothing has been written about it in 4 years.

Namespaces are only part of the answer. That isolates kubernetes objects impacting other kubernetes objects, but you also need to worry about shared resources like the ingress namespace. If containers share worker nodes, then there are resource limits to enforce. And the default network model used by kubernetes is flat with DNS exposing services and containers in other namespaces and an open network policy allowing any container to talk to any other container. The kubernetes API is also shared in a multi-tenant environment, allowing a DoS to the kubernetes infrastructure itself. And if users are allowed to run containers with added capabilities, privileged access, host bind mounts, host namespaces, and probably many other features, they can escape the container isolation and get root access on the host running the containers. None of this is trivial to implement securely.