How to Secure Multi‑Tenant Kubernetes Clusters: Best Practices & Strategies

Securing multi‑tenant Kubernetes clusters is crucial for enterprises moving to the cloud. This article discusses the concept of multi‑tenant clusters, common usage patterns, business scenarios for shared clusters, and Kubernetes’s built‑in security management features.

What is a Multi‑Tenant Cluster

First, we define “tenant”. A tenant includes not only cluster users but also the workloads that constitute compute, network, storage, and other resources. In a multi‑tenant cluster, isolation between different tenants prevents malicious tenants from attacking others and enables reasonable resource sharing. Based on the security level, clusters can be soft multi‑tenancy or hard multi‑tenancy. Soft isolation suits internal enterprise clusters where tenants are trusted; it mainly protects internal teams and guards against potential attacks. Hard isolation is needed for service providers offering external services, where tenants may have unknown security backgrounds, requiring strict isolation.

Multi‑Tenant Use Cases

Two enterprise multi‑tenant scenarios with different isolation requirements are introduced:

Enterprise‑Internal Shared Cluster

All cluster users come from the same enterprise, a common scenario for many Kubernetes customers. Because user identities are controllable, security risks are relatively manageable. The enterprise can use namespaces to logically isolate resources for different departments or teams and define the following roles:

Cluster Administrator

Has cluster management capabilities such as scaling and adding nodes.

Creates and assigns namespaces for tenant administrators.

Manages policies like RAM, RBAC, NetworkPolicy, and quotas.

Tenant Administrator

At least read‑only access to cluster RAM.

Manages RBAC configuration for personnel within the tenant.

Tenant User

Uses Kubernetes resources within the allowed range of the tenant’s namespace.

Beyond role‑based access control, network isolation between namespaces must be ensured; only whitelisted cross‑tenant application requests are allowed.

SaaS and KaaS Service Models

In SaaS multi‑tenant scenarios, tenants are service‑application instances on the SaaS platform and control plane. Each tenant runs in a separate namespace, and end users access the SaaS console rather than the Kubernetes control plane directly. For example, a blog platform deployed on a multi‑tenant cluster has each customer’s blog instance and the platform control plane in different namespaces.

KaaS (Kubernetes‑as‑a‑Service) scenarios involve cloud providers exposing the Kubernetes control plane to different tenants. Tenants must be isolated via namespaces, and both network and resource‑quota isolation are required.

Unlike internal shared clusters, end users in SaaS/KaaS are untrusted, so stronger security isolation is needed. Native Kubernetes features are insufficient, requiring kernel‑level isolation at runtime to enhance tenant security.

Implementing Multi‑Tenant Architecture

When planning and implementing a multi‑tenant cluster, start with a resource isolation model that layers the cluster itself, namespaces, nodes, Pods, and containers. Controlling the resource domain each tenant can access reduces security risks. At the scheduling level, ensure containers handling sensitive data run on dedicated nodes.

Although Kubernetes’s native security and scheduling are insufficient for complete isolation, namespace isolation combined with RBAC, PodSecurityPolicy, NetworkPolicy, and other policy models can reliably control tenant resource access and scheduling.

The following sections focus on multi‑tenant practices based on Kubernetes native security features.

Access Control

NetworkPolicy

NetworkPolicy controls network traffic between Pods of different tenants and uses whitelists for cross‑tenant access.

PodSecurityPolicy

PodSecurityPolicies (PSP) are cluster‑level resources that validate Pod creation against security requirements, such as host network usage, privileged containers, and set security contexts (UID, GID, kernel capabilities, etc.).

OPA

Open Policy Agent (OPA) provides a decoupled policy engine for fine‑grained access control beyond RBAC. It supports extended NetworkPolicy definitions and label‑based cross‑namespace controls, enhancing Kubernetes native policies.

Resource Scheduling

ResourceQuota and LimitRange

In multi‑tenant scenarios, teams share cluster resources, which can lead to contention. ResourceQuota limits total resource requests per namespace, while LimitRange sets default request and limit values for Pods within a tenant’s namespace. Storage and object‑count quotas can also be enforced.

Pod Priority and Preemption

Since Kubernetes 1.14, Pod priority and preemption allow high‑priority Pods to evict lower‑priority ones, protecting critical workloads. Combining priority with ResourceQuota can enforce quota limits for high‑priority workloads.

Dedicated Nodes

Note: Malicious tenants may bypass node taint and tolerance mechanisms. The following applies only to trusted tenants or clusters where tenants cannot directly access the Kubernetes control plane.

Adding taints to specific nodes reserves them for designated tenants (e.g., GPU nodes). However, malicious tenants can add matching tolerations, so taints alone cannot guarantee security in untrusted multi‑tenant clusters.

Protecting Sensitive Information – Secret Encryption

In multi‑tenant clusters, all tenants share the same etcd store. Encrypting Secrets protects sensitive data when control‑plane access is misconfigured.

Conclusion

When deploying a multi‑tenant architecture, first identify the application scenario, the trust level of tenant users and applications, and the required isolation degree. To meet basic isolation requirements, it is recommended to:

Enable Kubernetes default security configurations.

Enable RBAC and disable anonymous access.

Enable secret encryption to protect sensitive information.

Follow the CIS Kubernetes benchmark for security hardening.

Enable admission controllers such as NodeRestriction, AlwaysPullImages, and PodSecurityPolicy.

Use PSP to control privileged Pod deployment and enforce security contexts at runtime.

Configure NetworkPolicy.

Enable Seccomp, AppArmor, and SELinux for Docker runtime.

Isolate monitoring, logging, and other services per tenant.

For SaaS and KaaS models or when tenant trust cannot be guaranteed, stronger isolation measures are advisable:

Use OPA dynamic policy engine for fine‑grained network or object‑level access control.

Deploy secure containers with kernel‑level isolation at runtime.

Implement comprehensive multi‑tenant isolation for monitoring, logging, storage, and other services.