Multi-tenancy

Kratix does not introduce a custom multi-tenancy layer. Instead, it fits into the same Kubernetes isolation patterns you already use. Depending on your security and operational requirements, you can isolate tenants with separate clusters, node pools, or namespaces.

Separate clusters are often used to reduce blast radius or to meet DR/HA or regulatory requirements. Node pools help ensure workloads and workflows run on the right type of compute (for example, dedicated, compliant, or GPU nodes). Namespaces provide a lightweight boundary for teams. For example, an organisation might allocate backend and frontend namespaces so each team can manage their own Promise requests independently from the same Platform.

Kratix Promises can create namespaced CRDs and therefore resource requests (for example a Kratix Promise for Database or App) will be namespaced. This makes namespaces a natural boundary for teams, environments, or organisations. You can then combine namespaces with Kubernetes features like ResourceQuotas and NetworkPolicies to enforce limits and isolation per team or other organisational division.

Promises themselves are cluster-scoped and are not namespaced. That means a Promise is visible across the cluster once installed. Use Kubernetes RBAC to control who can list Promises and who can create request resources in each namespace. See the Kratix RBAC guide for examples and guidance.

For the Kubernetes details, see the Namespaces docs.