Answers: <p>There's an active <a href="https://github.com/kubernetes-sigs/multi-tenancy" rel="nofollow noreferrer">SIG devoted to multitenancy</a> so I have a hard time believing that nothing has been written about it in 4 years.</p>
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-12-09T19:29:09.373Z
Answers: Right. https://github.com/kubernetes/kubernetes/issues/97076 is just an recent example I found of multiple issues that arise from this.
Answers: omni
Answers: CC BY-SA 4.0
Answers: 2020-12-09T16:04:24.370Z
Answers: 2020-12-09T16:04:24.370Z
Answers: BMitch
Body: <p>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 <a href="https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/" rel="nofollow noreferrer">this article from 2016</a> sais</p>
  <blockquote>
  <p>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 [...]</p>
  </blockquote>
  <p>With <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">RBAC</a> it's now possible to set permissions on a specific namespace and thus restrict authenticated users to specific namespaces and their resources.</p>
  <p>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. <strong>Is that correct?</strong>
  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?</p>
  <p>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 &quot;acceptable&quot;, are namespaces really a good tool for tenant isolation?</p>
  
Tags: <kubernetes>
Title: Kubernetes namespaces with RBAC: sufficient for tenant isolation in a public environment?
UserDisplayName: omni
ThreadText: # Kubernetes namespaces with RBAC: sufficient for tenant isolation in a public environment?
  
  (Asked by: username_0 on 2020-12-08)
  
  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](https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/) 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](https://kubernetes.io/docs/reference/access-authn-authz/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?
  
  **Tags:** kubernetes
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-12-09. Score: 1 | Accepted answer
  
  There's an active [SIG devoted to multitenancy](https://github.com/kubernetes-sigs/multi-tenancy) 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.
  
  > **Comments:**
  > **username_0**: Right. https://github.com/kubernetes/kubernetes/issues/97076 is just an recent example I found of multiple issues that arise from this.  
  
  ---
  
  