Multi-Tenancy in DKP

What Is Multi-Tenancy?

You can use workspaces to manage your tenants' environments separately, while still maintaining control over clusters and environments centrally. For example, if you operate as a Managed Service Provider (MSP), you can manage your clients clusters' lifecycles, resources, and applications. If you operate as an environment administrator, you can these resources per department, division, employee group, etc.

Here are some important concepts:

Multi-tenancy

Multi-tenancy in DKP is an architecture model where a single DKP Enterprise instance serves multiple organization’s divisions, customers or tenants. In DKP, each tenant system is represented by a workspace. Each workspace and its resources can be isolated from other workspaces (by using separate Identity Providers), even though they all fall under a single Enterprise license.

Multi-tenant environments have at least two participating parties: the Enterprise license administrator (for example, an MSP), and one or several tenants.

Managed Service Provider or MSP

Managed Service Providers or MSPs are partner organizations that use DKP to facilitate cloud infrastructure services to their customers or tenants. For more information, see MSP Program.

Tenant

Tenants can be customers of Managed Service Provider partners. They outsource their cloud management requirements to MSPs, so they can focus on the development of their products.

Tenants can also be divisions within an organization that require a strict isolation from other divisions, for example, through differentiated access control.

In DKP, a workspace is assigned to a tenant.

How Does Access Control Work in Multi-Tenant Environments?

To isolate each tenant’s information and environment, multi-tenancy allows you to configure an identity provider per workspace or tenant. In this setup, DKP keeps all workspaces and tenants separate and isolated from each other.

Multi-tenancy example with one Management cluster, and two tenants. The Management Cluster manages two workspaces or tenants. Each workspace or tenant can host multiple Projects. Each priject can host one or multiple clusters. Clusters can be assigned to one or several projects, but not to several Workspaces. — Multi-tenancy example with one Management cluster, and two tenants.

You, as a global administrator, manage tenant access at the Workspace level. A tenant can further adapt user access at the Project level.

Workspaces and Projects

Workspaces: In a multi-tenant system, workspaces and tenants are synonymous. You can set up an identity provider to control all workspaces, including the Management cluster’s kommander workspace. You can then set up additional identity providers for each workspace/tenant, and generate a dedicated Login URL, so each tenant has its own user access.

Projects: After you set up an identity provider per workspace/tenant, the tenant can choose to further narrow down access with an additional layer. A tenant can choose to organize clusters into projects and assign differentiated access to user groups with Project Role Bindings.

By assigning clusters to one or several projects, you can enable more complex user access.

How Do I Enable Multi-Tenancy?

To enable multi-tenancy, you must:

Configure an Identity Provider globally, if you want to use a single IdP to access all of your tenant’s environments.
Configure an Identity Provider per workspace. This way, each tenant has a dedicated IdP to access their workspace.
Create DKP Identity Provider groups with the correct prefixes to map your existing IdP groups.
Create a dedicated login URL for each tenant. You can provide a workspace login link to each tenant for access to the DKP UI and for the generation of kubectl API access tokens.

To enforce security, every tenant should be in a different AWS account, so they are truly independent of each other.

Next Step:

Generate a Dedicated URL Login for Each Tenant