Overview
Multitenancy typically means that a Kubernetes cluster and its control plane are shared by multiple users, workloads, or applications. Two types of multitenancy are supported in the platform.
- Multitenancy (based on Kubernetes Namespaces)
- Soft Multitenancy (based on Workspaces)
It should be noted that unlike hard isolation (single tenant), multitenancy cannot impose strict isolation of the different users, workloads, or applications. It is an appropriate solution for trusted and known tenants, i.e. tenants that will not voluntarily abuse each other such as engineers within the same organization. The isolation between users is rather focused on preventing accidents and cannot prevent attacks on other tenants.
Automation Options¶
The below matrix presents a breakdown of actions like creation, updating, and deletion—for Kubernetes Namespaces across multiple deployment methods: interactive UI, declarative RCTL commands, API-driven automation, and Terraform.
| Action | UI | CLI | API | Terraform |
|---|---|---|---|---|
| Create | Yes | Yes | Yes | Yes |
| Edit/Update | Yes | Yes | Yes | Yes |
| Delete | Yes | Yes | Yes | Yes |
Namespaces¶
Kubernetes natively provides the means to logically separate a cluster into multiple virtual clusters called "namespaces". Namespaces are intended for situations where multiple users need to share the same Kubernetes cluster. Namespaces can be configured to ensure that each user or application exists within its namespace and is isolated from every other user of the cluster.
The Kubernetes Operations Platform provides a number of critical capabilities that enable an Organization to augment a namespace with additional "enforcement controls" to ensure that inadvertent and malicious attempts to break multitenancy is significantly reduced.
A commonly used term for this multitenant model is Namespace as a Service.
Access Control¶
Organizations can leverage Role(s) and RoleBinding(s) to restrict which users can access a particular namespace and with what privileges (i.e. read, read/write etc.)
Resource Quota Enforcement¶
Organizations can leverage "Resource Quotas" to restrict how much of the cluster resources a namespace can use.
Network Isolation¶
Organizations can leverage the integrated "network policies" service to control how resources in a namespace can interact with each other and outside the namespace.
Secure Communication¶
Organizations can optionally leverage the integrated Istio based "service mesh" service to enforce "mTLS" based secure communication between services in a namespace.
