Tenant Layer¶

The tenant layer provides physical and logical separation for tenant workloads. Each tenant cluster operates in an isolated environment with dedicated resources.

Tenant Layer Architecture¶

Physical Boundaries¶

Tenant clusters operate in isolated environments separate from the under cluster.

Infrastructure Isolation¶

Each tenant cluster has dedicated compute, storage, and network resources. Resources are not shared with other tenants or the under cluster.

Network Isolation¶

Tenant clusters operate in separate network segments using VPCs, VLANs, or equivalent isolation. This prevents network-level communication between tenants.

Control Plane Connectivity¶

Tenant worker nodes connect to their hosted control planes with security and isolation enforced.

Control Plane Separation¶

Each tenant control plane serves only its own cluster. Resource quotas, network policies, and RBAC enforce isolation between tenant control planes.

Secure Communication Channels¶

Communication between tenant worker nodes and control planes uses mutual TLS encryption with tenant-specific certificates.

Load-Balanced Endpoints¶

Each tenant control plane has a dedicated load balancer endpoint accessible only to the tenant's worker nodes and authorized users. The endpoint distributes traffic across control plane replicas.

Certificate-Based Authentication¶

Worker nodes authenticate using client certificates generated for each tenant cluster. Certificates cannot be used to access other tenant clusters.

API Boundary Protection¶

Tenant clusters cannot access other tenants' Kubernetes APIs, secrets, or configuration. Each control plane serves only its own cluster.

External Access to Tenant Clusters¶

External access maintains isolation while providing connectivity:

Ingress Controllers¶

Tenant clusters can deploy ingress controllers within their network segment for external traffic routing and SSL termination.

Load Balancer Services¶

Tenant clusters use LoadBalancer-type services fulfilled by infrastructure-specific load balancers within the tenant's network segment.

VPN and Direct Connect¶

Tenant clusters can connect to corporate networks through VPN or dedicated links within the tenant's network segment.

Hard Multi-Tenancy¶

kMetal does not rely on namespace isolation to keep tenants apart. Two tenants on the same hardware can share the under cluster, but their workloads do not share the kernel, do not share the network domain, and do not share a control plane. Three concurrent isolation boundaries combine to produce what we call hard multi-tenancy.

Compute isolation — kernel-level via KVM¶

Every tenant worker node is a KubeVirt virtual machine on the under cluster. The hypervisor is KVM, which runs in the Linux kernel of each compute host. A tenant's containers run inside the tenant's own kernel, inside the tenant's VM, so a container escape only buys an attacker access to that tenant's VM — not to the host, the under cluster, or any other tenant.

Network isolation — VPC per tenant via Kube-OVN¶

Each tenant gets a dedicated VPC (an OVN logical router with its own routing table) and one or more Subnets within it. Cross-VPC traffic is dropped by default; a tenant cannot reach another tenant's pods, services, or worker nodes, even if it knows their IPs. The default policy on the under cluster's OVN Logical Router blocks tenant traffic to platform IPs, so a tenant cannot reach the under cluster's API server or platform services either.

Two networking modes ship: overlay (Geneve tunnels, the default) and VLAN (per-tenant physical VLANs on the data-center switch). Overlay isolates without any per-tenant switch configuration. VLAN isolates at the wire layer and matches existing physical-network governance.

See Networking for the VPC and Subnet model in depth.

Control-plane isolation — dedicated etcd per tenant¶

Every tenant gets its own hosted Kubernetes control plane (api-server, controller-manager, scheduler, konnectivity-server) running as pods on the under cluster's CP nodes — and its own etcd instance backing that control plane. One tenant's etcd is not visible to another, even though both run on shared hardware. Authentication into each tenant cluster is independent: tenant kubeconfigs do not work against other tenants.

Each tenant gets a full Kubernetes cluster with cluster-admin access. The kMetal operator sets the boundaries (allowed versions, quotas, mandatory add-ons); inside those boundaries the tenant manages their cluster as their own.