The Fortress in the Cluster:

In many growing platform and eCommerce architectures, Kubernetes is considered the de facto standard for scalability and resilience. However, when multiple tenants are operated on a shared infrastructure, Kubernetes’ default configuration reveals its vulnerable side: Namespaces provide only logical grouping by default, but no reliable isolation at the network, CPU, or memory level.

Hard Multi-Tenancy bridges this gap. By combining uncompromising namespace hardening, strict NetworkPolicies in default-deny mode, and precise resource countermeasures via cgroups v2 and PriorityClasses, a multi-tenant platform is created that combines maximum cost efficiency in a shared cluster model with the security of physically separated servers.

The Problem: The Deceptive Security of Standard Namespaces

Without deep hardening, operating multiple tenants on a shared cluster inevitably leads to security risks and unpredictable performance degradation. The belief that namespaces are isolated security boundaries is a dangerous misconception.

1. The Flat-Network Security Risk

In the default state of a Kubernetes cluster, any pod can communicate unrestrictedly with any other pod across namespace boundaries at Layer 3 and Layer 4 levels. If an attacker compromises a single customer instance via a web vulnerability, the entire internal overlay network is open for lateral movement and unauthorized access to neighboring tenants.

2. The Noisy-Neighbor Effect

If a tenant experiences unexpected load spikes—such as through marketing campaigns, faulty batch jobs, or DDoS traffic—their pods uncontrollably compete for shared resources on the worker nodes. Without strict limits, this one tenant deprives neighboring instances of CPU cycles and RAM, leading to latency spikes, timeouts, and cascading effects (OOMKills) throughout the cluster.

3. Unregulated Access to Control Plane Resources

Without granular ResourceQuotas, a single tenant can overload the Kubernetes API server and the etcd backend through faulty deployment loops or excessive object creation. This not only affects their own instance but cripples the entire control plane for all other tenants and platform services.

The Solution: The Three-Pillar Model for Hard Multi-Tenancy

ayedo establishes Hard Multi-Tenancy not as an after-the-fact configuration discipline but as a declarative platform foundation. The isolation synchronously applies at the network, compute, and API levels.

1. Zero-Trust Network Segmentation via Default-Deny

Every newly provisioned tenant namespace automatically receives a baseline NetworkPolicy that blocks all incoming and outgoing traffic (Ingress and Egress) by default. Only dedicated, signed policies specifically open ports for the respective ingress controller, internal databases, and explicitly authorized external endpoints. Any cross-namespace communication is deterministically discarded at the CNI level via eBPF or iptables.

2. Deterministic Compute Governance with LimitRanges and cgroups v2

To exclude resource cannibalization, the platform enforces the definition of resources.requests and resources.limits via admission webhooks. LimitRanges ensure that containers without explicit limits cannot be started. The kernel subsystem cgroups v2 ensures that CPU throttling applies granularly and memory limits, when exceeded, isolate and terminate only the causing container (OOMKilled), without endangering neighboring workloads on the node.

3. API Budgeting and PriorityClasses

Cluster-wide ResourceQuotas hard cap the maximum number of pods, services, PersistentVolumeClaims, and secrets per tenant. Additionally, PriorityClasses assign higher scheduling priorities to business-critical production instances than to staging or test workloads, allowing Kubernetes to specifically evict non-critical pods during bottlenecks to keep SLA-critical tenants stable.

Strategic and Economic Value

• Dramatic TCO Reduction Compared to VM Silos: By sharing the Kubernetes control plane and worker nodes, infrastructure costs decrease by 40% to 60% compared to dedicated VM clusters per customer, with equivalent isolation.
• Complete NIS-2 and DORA Compliance: The seamless network isolation and tenant-specific access control meet regulatory requirements for segmentation, access protection, and resilience in critical industries.
• Auditable GDPR Tenant Separation: Strict default-deny network rules ensure that data flows between tenants are technically impossible, significantly speeding up compliance audits and customer certifications.
• Sovereign Operation on European IaaS: Hard Multi-Tenancy runs independently of proprietary hyperscaler features on standardized hardware with European providers like Hetzner or IONOS—without reliance on expensive cloud-specific IAM ecosystems.

Conclusion

Hard Multi-Tenancy proves that maximum resource density and uncompromising security are not contradictions but the result of clean platform architecture. Securing Kubernetes through declarative policies and strict kernel resource control not only protects sensitive customer data from lateral threats but also scales the operational model with predictable costs and absolute reliability.

Frequently Asked Questions (FAQ)

Is Hard Multi-Tenancy sufficient to securely execute malicious foreign code?

For standard SaaS and eCommerce applications with a trusted code base, this model offers excellent protection. However, if arbitrary, untested foreign codes or user scripts need to be executed, the platform should additionally be extended with container sandboxing technologies like gVisor or Kata Containers (MicroVMs) at the node level to secure against a kernel breach.

Does enforcing hard CPU limits lead to unnecessary performance loss?

No, if CPU requests and CPU limits are strategically dimensioned. By using cgroups v2 in modern Linux kernels, the CFS bandwidth quota system operates extremely precisely. Workloads receive guaranteed minimum compute time, while load spikes are absorbed within defined corridors without slowing down other tenants.

How is it ensured that developers do not accidentally deploy unsecured namespaces?

This is guaranteed by GitOps in combination with Kubernetes admission controllers (such as Kyverno or OPA Gatekeeper). If a pipeline attempts to roll out a namespace manifest or a pod without a valid NetworkPolicy, ResourceQuota, or LimitRange, the admission controller blocks the API call before creation.