Namespace Limitations, Anti-Patterns, and Community Resources

In situations where confidentiality or compliance require complete opaqueness between customers, a Kubernetes cluster per customer/workload will provide the desired level of isolation. Once again, you should delegate the partitioning of resources to your provider. Work is underway to provide (a) ACLs on Kubernetes Namespaces to be able to enforce security; (b) to provide Kubernetes [Cluster Federation](https://kubernetes.io/blog/2016/07/cross-cluster-services). Both mechanisms will address the reasons for the separate Kubernetes clusters in these anti-patterns.  An easy to grasp **anti-pattern** for Kubernetes namespaces is versioning. You should not use Namespaces as a way to disambiguate versions of your Kubernetes resources. Support for versioning is present in the containers and container registries as well as in Kubernetes Deployment resource. Multiple versions should coexist by utilizing the Kubernetes container model which also provides for auto migration between versions with deployments. Furthermore versions scope namespaces will cause massive proliferation of namespaces within a cluster making it hard to manage. **Caveat Gubernator** You may wish to, but you cannot create a hierarchy of namespaces. Namespaces cannot be nested within one another. You can’t, for example, create my-team.my-org as a namespace but could perhaps have team-org. Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-).  As mentioned previously, Kubernetes does not (currently) provide a mechanism to enforce security across Namespaces. You should only use Namespaces within trusted domains (e.g. internal use) and not use Namespaces when you need to be able to provide guarantees that a user of the Kubernetes cluster or ones its resources be unable to access any of the other Namespaces resources. This enhanced security functionality is being discussed in the Kubernetes Special Interest Group for Authentication and Authorization, get involved at [SIG-Auth](https://github.com/kubernetes/kubernetes/wiki/SIG-Auth).  - [Download](http://get.k8s.io/) Kubernetes - Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) - Connect with the community on [Slack](http://slack.k8s.io/) - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates

For complete isolation, a Kubernetes cluster per customer is recommended. Future features like ACLs and Cluster Federation aim to address this. Avoid using namespaces for versioning; use container versioning instead. Namespaces cannot be nested. Automation and kubectl contexts can prevent accidental deployment to the wrong namespace. Namespaces don't enforce security; use them in trusted domains. Contribute to Kubernetes through GitHub, Stack Overflow, Slack, and Twitter.