Kubernetes Multi-Tenancy Models for Regulated Healthcare Platforms

Healthcare SaaS platforms often need to run applications for multiple hospitals, health plans, practices, or digital health customers on Kubernetes. Sharing infrastructure can reduce operating costs and simplify platform management. It can also create cross-tenant risks involving electronic protected health information, application availability, administrative access, and shared platform dependencies.

Kubernetes does not contain a native tenant object or a single multi-tenancy switch. Instead, platform teams combine namespaces, authorization, network controls, workload security, storage configuration, resource governance, and sometimes separate control planes or clusters.

For regulated healthcare workloads, the correct design must follow a documented risk analysis. No Kubernetes topology is inherently HIPAA compliant.

Single-Tenant vs. Multi-Tenant Kubernetes

A single-tenant Kubernetes architecture dedicates a cluster, or a separately controlled platform environment, to one healthcare organization, business unit, or customer. The tenant does not share the Kubernetes cluster with unrelated tenants, although underlying cloud services, identity systems, networks, registries, databases, or monitoring platforms may still be shared.

A multi-tenant Kubernetes architecture allows multiple teams, customers, or workloads to share part of the same Kubernetes platform. Depending on the design, tenants may share the control plane, worker nodes, networking components, storage infrastructure, or operational services.

The main difference is the extent of shared infrastructure and the controls required to prevent one tenant from accessing, disrupting, or consuming resources assigned to another tenant.

A single-tenant cluster can reduce Kubernetes-level cross-tenant risk, but it does not automatically provide complete isolation. Cloud accounts, networks, encryption keys, identity services, CI/CD systems, databases, backups, and observability platforms must also be evaluated.

Multi-tenancy can improve infrastructure utilization and centralize platform operations, but it requires deliberate control-plane and data-plane isolation.

What Are the Planes? And Understanding the Two Isolation Planes

In Kubernetes architecture, a plane is a functional part of the platform responsible for a specific category of operations.

A Kubernetes cluster consists of a control plane and one or more worker nodes. The control plane manages cluster state and makes decisions about workloads. Worker nodes run the Pods and containers that deliver the application.

In a multi-tenant architecture, these components create two related isolation areas:

• Control-plane isolation, which protects Kubernetes API resources and administrative operations
• Data-plane isolation, which protects running workloads, networks, nodes, storage, and runtime resources

A multi-tenant Kubernetes architecture must evaluate these two areas separately because a control that strengthens one plane may not fully isolate the other.

Control-Plane Isolation

The control plane manages Kubernetes API resources and cluster state. Control-plane isolation determines whether one tenant can access or modify another tenant’s:

• Deployments and Services
• Secrets and ConfigMaps
• Admission policies
• CustomResourceDefinitions
• Operators
• Cluster-scoped resources

Data-Plane Isolation

The data plane includes the worker nodes and running workloads. Data-plane isolation addresses:

• Pod-to-Pod communication
• Shared worker-node kernels
• Storage attachment
• Runtime escape risk
• Resource contention
• Shared ingress, DNS and observability services

A virtual control plane can strengthen API isolation without fully isolating worker nodes. 

Dedicated nodes can improve workload isolation without creating a separate Kubernetes control plane. These controls should not be treated as interchangeable.

Model 1: Namespace per Tenant

The namespace-per-tenant model places each healthcare customer or internal team in one or more namespaces within a shared cluster.

Namespaces scope many Kubernetes objects, including Deployments, Services, Secrets, Roles, RoleBindings, NetworkPolicies, ResourceQuotas, and LimitRanges.

This model offers the lowest infrastructure overhead because tenants share:

• The Kubernetes control plane
• Worker-node capacity
• Cluster networking
• Platform services
• Operational tooling

However, namespaces do not isolate cluster-scoped resources such as Nodes, StorageClasses, PersistentVolumes, and CustomResourceDefinitions. A namespace is therefore an organizational and policy boundary, not a complete security boundary by itself.

Enforcing a Pod Security Standard

Pod Security Admission can apply Kubernetes Pod Security Standards at the namespace level. The following example instructs the admission controller to enforce the Restricted profile for Pods created in the namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: tenant-a-prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

This is an illustrative starting point, not a complete tenant configuration.

The Restricted policy can reject Pods that require prohibited privileges or host access. Platform teams should test existing workloads before enforcement and document any approved exceptions.

Namespace tenancy is most suitable when the organization accepts shared control-plane and worker infrastructure after security controls are applied.

Model 2: Virtual Control Plane per Tenant

A virtual-control-plane model provides each tenant with logically separate Kubernetes control-plane components. Depending on the implementation, these may include a tenant-facing API server, controller manager, and control-plane data store.

This provides stronger separation for Kubernetes API resources, including cluster-scoped resources that cannot be isolated through namespaces alone.

A virtual control plane may be appropriate when tenants require:

• Kubernetes API access
• Tenant-specific operators
• Separate CustomResourceDefinitions
• Independent admission behavior
• Greater control over cluster-wide resources

Worker nodes may still belong to a shared host cluster. Therefore, the model does not automatically isolate node kernels, networking, storage infrastructure, ingress components, or resource consumption.

Virtual control planes may need to be combined with restricted node pools, network isolation, sandboxed runtimes, and tenant-specific storage controls.

The exact security properties depend on the selected virtual-control-plane implementation.

Alternative: Dedicated Cluster per Tenant

A dedicated cluster gives a tenant a separate Kubernetes control plane and separate worker capacity.

It provides stronger Kubernetes-level separation than namespace-only or virtual-control-plane models. It may be selected when required by the threat model, customer contract, workload trust level, availability target, or accepted blast radius.

However, separate Kubernetes clusters can still share:

• Cloud accounts or subscriptions
• Identity providers
• Virtual networks
• Container registries
• CI/CD credentials
• Databases
• Encryption keys
• Backup platforms
• Monitoring systems

These supporting services must be evaluated separately. A dedicated Kubernetes cluster does not automatically establish complete tenant isolation.

This model also increases operational requirements for upgrades, vulnerability remediation, policy distribution, backup, recovery, monitoring, and configuration-drift management.

Network Isolation Between Tenants

By default, Pods are not isolated for ingress or egress merely because they are placed in different namespaces.

Kubernetes NetworkPolicy can control permitted Layer 3 and Layer 4 traffic for selected Pods. Enforcement requires a network plugin that supports NetworkPolicy.

A tenant namespace can begin with a default-deny policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: tenant-a-prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

This policy selects every Pod in the namespace and permits no ingress or egress traffic through the policy itself.

It must be followed by explicit allow policies for required communication, including DNS, ingress controllers, identity services, monitoring endpoints, databases, healthcare interfaces, and approved external APIs.

NetworkPolicy does not encrypt traffic. Transport encryption requires application protocols, service-mesh capabilities, network-layer encryption, or another approved mechanism.

Resource Governance and Noisy Neighbors

A tenant can affect other tenants by consuming shared CPU, memory, storage, network, or platform-service capacity.

ResourceQuota restricts aggregate resource consumption within a namespace. LimitRange can define defaults or constraints for individual containers and Pods.

The following example demonstrates how these objects work together:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-compute-budget
  namespace: tenant-a-prod
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "40"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-container-defaults
  namespace: tenant-a-prod
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 250m
        memory: 256Mi
      default:
        cpu: "1"
        memory: 1Gi

The values are illustrative and must be replaced with figures derived from workload profiling, capacity planning, and service-level requirements.

These controls do not isolate every shared resource. Network bandwidth, storage throughput, DNS, ingress controllers, logging pipelines, admission webhooks, and control-plane capacity may require additional controls.

Secrets, Storage, and ePHI

Kubernetes Secret values are base64-encoded. Base64 encoding is not encryption.

Upstream Kubernetes stores Secret data unencrypted in etcd by default unless encryption at rest is configured. Managed Kubernetes services may provide different defaults, which must be verified for the specific service and configuration.

Regulated platforms should evaluate:

• Encryption of Kubernetes API data at rest
• Least-privilege access to Secrets
• Workload identity
• Secret rotation
• External secret-management systems
• Access logging
• Key-management responsibilities

PersistentVolumeClaims are namespaced, but PersistentVolumes are cluster-scoped. StorageClasses, reclaim policies, snapshots, backups, encryption, and volume reuse must be evaluated for cross-tenant exposure.

Kubernetes API-data encryption also does not automatically encrypt application data stored inside mounted volumes. Volume or application-level encryption is a separate control.

Auditing Tenant Activity

Kubernetes auditing can record API activity generated by users, workloads, and control-plane components.

An audit policy determines which requests are recorded and how much information each event contains. Audit logging should not be assumed to be active without verifying the cluster or managed-service configuration.

For a healthcare platform, audit design should support investigation of:

• RBAC changes
• Secret access
• Privileged workload creation
• Namespace-policy changes
• Admission-control changes
• Cross-tenant access attempts
• Administrative break-glass activity

Audit records must also be handled carefully because request metadata or object content could contain sensitive information.

Selecting the Right Model

A defensible selection process should:

1. Identify where ePHI is created, received, maintained, or transmitted.
2. Define what constitutes a tenant.
3. Determine whether tenants can access the Kubernetes API.
4. Evaluate whether tenants can deploy custom or untrusted code.
5. Map shared control-plane, node, network, storage, and operational dependencies.
6. Select control-plane and data-plane isolation independently.
7. Document residual risks and compensating controls.
8. Test authorization, network, storage, workload, and resource boundaries.
9. Reassess the model when workloads, threats, contracts, or platform components change.

Design Your Healthcare Kubernetes Architecture With CapMinds

Kubernetes multi-tenancy requires more than creating separate namespaces. 

Healthcare platforms need a risk-based design that connects tenant isolation with cloud security, workload protection, storage governance, auditability, disaster recovery, and compliance evidence.

CapMinds helps healthcare organizations and digital health companies:

• Assess tenant isolation and cross-tenant risk
• Select namespace, virtual-control-plane, or dedicated-cluster models
• Design secure healthcare cloud and Kubernetes architectures
• Implement network, workload, secrets, and storage controls
• Establish centralized monitoring and compliance evidence
• Strengthen backup, recovery, and operational resilience

Schedule a Kubernetes Architecture Assessment