Overview
Although namespaces provide the ability to logically partition a cluster, it is not possible to truly enforce partitioning. This means users or resources operating in the same Kubernetes cluster can access any other resource in the cluster regardless of the namespace it is operating in.
Even if compensating controls such as Network Policies are implemented to block/control "namespace-to-namespace" communication, there is still the "noisy neighbor" problem to consider.
For scenarios where this can be problematic, the only practical solution is to use "dedicated" Kubernetes clusters to guarantee true separation across operational boundaries.
A commonly used term for this single tenant model is Cluster as a Service.
One common example for this is the use of a dedicated cluster for "Production" and "Staging". Users can use "Projects" to achieve this isolation. An illustrative example is shown below.
| Environment | Project |
|---|---|
| Production | "Production" Project with a dedicated Kubernetes cluster. Project configured with least privilege RBAC so that only required users can access the project |
| Staging | "Staging" Project with a dedicated Kubernetes cluster. Project configured with RBAC so that only required users can access the project |
One or multiple Kubernetes clusters can exist in a Project. In the example below, an Amazon EKS cluster has been provisioned in the Project.
Users within a project can switch to another project using the search bar. When a user initiates a search with a specific letter(s) (for example, qe), the system auto complete the search and list out all the project names corresponding to the entered text (qe) as shown in the below example
Access Control¶
Organizations can restrict which users can access a particular project and with what privileges (i.e. read, read/write etc.) using role based access control
Resource Quotas¶
Organizations can leverage "Resource Quotas" to restrict how much of the cluster resources a namespace can use.
