# Hard Multi-Tenancy in Kubernetes

DevFeed: [Hard Multi-Tenancy in Kubernetes](<https://devfeed.tech/articles/hard-multi-tenancy-in-kubernetes-35168.md>)

Original publisher: [Read original article](<https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/>)

Published: 2018-05-18T19:17:58Z

Content type: article

Language: en

Sources: [Jessie Frazelle](<https://devfeed.tech/sources/jessie-frazelle.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Multitenancy](<https://devfeed.tech/topics/multitenancy.md>), [Security](<https://devfeed.tech/topics/security.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Software as a service](<https://devfeed.tech/topics/saas.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [multi-tenancy](<https://devfeed.tech/tags/multi-tenancy.md>), [security](<https://devfeed.tech/tags/security.md>), [vulnerabilities](<https://devfeed.tech/tags/vulnerabilities.md>)

## AI overview

This article examines hard multi-tenancy in Kubernetes, where tenants sharing a cluster are assumed not to trust one another. It argues that Kubernetes namespace isolation is not yet a sufficient security boundary and discusses the need for layered security, including isolation of the Kubernetes API.

## Source excerpt

EDIT: See my post on a design doc for a multi-tenant orchestrator instead. I wrote this when an internal requirement was to use Kubernetes but I do not personally think you should use Kubernetes for this use case. Kubernetes is the new kernel. We can refer to it as a "cluster kernel" versus the typical operating system kernel. This means a lot of great things for users trying to deploy applications. It also leads to a lot of the same challenges we have already faced with operating system kernels. One of which being privilege isolation. In Kubernetes, we refer to this as multi-tenancy, or the dream of being able to isolate tenants of a cluster. The models for multi-tenancy have been discussed at length in the community's multi-tenancy working group. NOTE: to view most of these Google docs you need to be a member of the kubernetes-wg-multitenancy Google group. There have also been some proposals offered to solve each model. The current model of tenancy in Kubernetes assumes the cluster is the security boundary. You can build a SaaS on top of Kubernetes but you need to bring your own trusted API and not just use the Kubernetes API. Of course, with that comes a lot of considerations you must also think about when building your cluster securely for a SaaS even. The model I am going to be focusing on for this post is "hard multi-tenancy." This implies that tenants do not trust each other and are assumed to be actively malicious and untrustworthy. Hard multi-tenancy means multiple tenants in the same cluster should not have access to anything from other tenants. In this model, the goal is to have the security boundary be the Kubernetes namespace object. The hard multi-tenancy model has not been solved yet, but there have been a few proposals. All systems have weaknesses and nothing is perfect. With a system as complex and large as Kubernetes it is hard to trust the entire system to not be vulnerable. In this regard and in the regard of the existing proposals, one single ex