# Overview

The platform offers several additional constructs to augment and implement Kubernetes multi-tenancy patterns in customer environments. A couple of them include:

- **Projects**: Logical "self-contained isolated units" that customers can leverage to compartmentalize infrastructure and resources belonging to different teams or applications

- **Workspace Admin role**: Enables a self-service model for application teams by providing an intermediate level of multi-tenancy beyond Kubernetes namespaces

In this self-paced exercise, you will learn to implement a couple of common multi-tenancy use cases:

- Teams have dedicated clusters assigned to them. Platform teams want to manage these clusters centrally and ensure that teams only have access to their respective clusters. We will use the **Project** construct to implement this use case

- Clusters are shared between teams. Platform teams want to enforce governance controls but not at the cost of slowing down application teams. For this use case, we will use a combination of **Project** and **Workspace Admin** constructs

* * *

## What Will You Do by Part

| Part | What will you do? |
| --- | --- |
| 1 | Implement ["Project" based isolation](https://docs.rafay.co/learn/quickstart/multi-tenancy/project_isolation/) for dedicated clusters |
| 2 | Implement ["Project + Workspace role" based isolation](https://docs.rafay.co/learn/quickstart/multi-tenancy/workspace_isolation/) for shared clusters |

* * *

## Prerequisites

You have access to an Org in the platform and a couple of K8s clusters that are upstream K8s compliant.