Lesson 09 — Kubernetes Multi-Tenant Security

Learning Objectives

By the end of this lesson, you will be able to:

Understand multi-tenancy in Kubernetes
Differentiate between soft and hard multi-tenancy
Design secure multi-tenant Kubernetes clusters
Understand Namespace isolation
Implement RBAC for tenant separation
Secure tenant communication using Network Policies
Apply Resource Quotas and Limit Ranges
Identify common multi-tenancy security risks
Apply enterprise best practices

Why This Matters

Modern enterprises rarely dedicate one Kubernetes cluster to a single application.

Instead, organisations commonly host:

Multiple development teams
Business units
Customers
Projects
Applications
Environments

…within the same Kubernetes cluster.

For example:

A financial organisation may run:

Online Banking
Credit Card Services
Loan Processing
Fraud Detection
Customer Portal

inside a shared Amazon EKS cluster.

Without proper isolation, one workload could accidentally—or intentionally—access another team’s applications or sensitive data.

Multi-tenant security ensures that each tenant remains isolated while sharing the same infrastructure.

What is Multi-Tenancy?

Multi-tenancy is the practice of allowing multiple independent tenants to share the same Kubernetes infrastructure securely.

A tenant may represent:

A team
A department
A customer
A project
A business unit
An application

Each tenant operates independently while sharing the cluster.

Multi-Tenant Architecture

Amazon EKS Cluster

├── Finance Team
│
├── Security Team
│
├── HR Team
│
├── Marketing Team
│
└── Operations Team

Although everyone shares the same cluster, security controls prevent unauthorised access between tenants.

Benefits of Multi-Tenancy

Multi-tenancy provides:

Better resource utilisation
Reduced infrastructure costs
Simplified management
Centralised monitoring
Easier governance
Faster deployments
Consistent security controls
Improved scalability

Large organisations commonly operate shared Kubernetes platforms to maximise efficiency.

Types of Multi-Tenancy

Kubernetes supports two primary models.

Model	Description
Soft Multi-Tenancy	Logical isolation within a shared cluster
Hard Multi-Tenancy	Strong isolation using dedicated clusters or virtual clusters

Choosing the right model depends on security, compliance, and operational requirements.

Soft Multi-Tenancy

Soft multi-tenancy uses Kubernetes security features to separate tenants.

Example:

Cluster

├── Namespace A

├── Namespace B

├── Namespace C

└── Namespace D

Isolation is achieved using:

Namespaces
RBAC
Network Policies
Resource Quotas
Pod Security Standards

This is the most common enterprise deployment model.

Hard Multi-Tenancy

Hard multi-tenancy provides stronger isolation.

Production Cluster

↓

Finance Cluster

↓

HR Cluster

↓

Government Cluster

Each tenant operates in a dedicated cluster or isolated Kubernetes environment.

Hard multi-tenancy is often required for:

Government
Defence
Healthcare
Financial services
Highly regulated industries

Namespace Isolation

Namespaces provide the first layer of tenant isolation.

Example:

Amazon EKS

├── finance

├── hr

├── security

├── operations

└── monitoring

Each Namespace contains its own:

Pods
Services
Secrets
ConfigMaps
Deployments

Namespaces prevent accidental interaction between teams.

RBAC Isolation

RBAC restricts tenant permissions.

Example:

Finance Developers

↓

Finance Role

↓

Finance Namespace

The Finance team cannot:

Read HR Secrets
Modify Security workloads
Delete Operations Pods

Each tenant receives only the permissions required for its Namespace.

Network Policies

Namespaces alone do not prevent network communication.

Network Policies define which Pods can communicate.

Finance Namespace

↓

Network Policy

↓

Only Finance Pods

Blocked:

HR Pod

↓

Finance Database

✗ Denied

Network Policies enforce Zero Trust networking within the cluster.

Resource Quotas

Resource Quotas prevent one tenant from consuming all cluster resources.

Example:

Finance Namespace

CPU

20 vCPU

Memory

64 GB

Pods

100

Without quotas, a single tenant could exhaust cluster capacity and impact other workloads.

Limit Ranges

Limit Ranges define default resource requests and limits.

Example:

Every Pod

CPU Request

500m

Memory Request

512Mi

CPU Limit

2 vCPU

Memory Limit

2Gi

This prevents poorly configured workloads from monopolising compute resources.

Pod Security Standards

Pod Security Standards restrict what workloads are allowed to do.

Examples include:

Prevent privileged containers
Restrict hostPath volumes
Prevent host networking
Block privilege escalation
Restrict Linux capabilities

These controls reduce the impact of compromised workloads.

Tenant Identity

Each tenant should have its own:

Namespace
RBAC Roles
Service Accounts
IAM Roles (IRSA)
Secrets
Network Policies

Example:

Finance

↓

Finance Service Account

↓

Finance IAM Role

↓

Finance Secrets

Tenant identities should never be shared.

Shared Services

Some services are intentionally shared across tenants.

Examples include:

Prometheus
Grafana
Fluent Bit
Amazon CloudWatch
AWS Security Hub
Amazon GuardDuty
AWS Config

Architecture:

Shared Monitoring Namespace

↓

Prometheus

↓

Grafana

↓

CloudWatch

Shared services should be carefully secured because they often have visibility across multiple tenants.

Enterprise Multi-Tenant Architecture

Amazon EKS Cluster

├── finance
│      ├── RBAC
│      ├── Network Policy
│      ├── IRSA
│      └── Resource Quota
│
├── hr
│      ├── RBAC
│      ├── Network Policy
│      ├── IRSA
│      └── Resource Quota
│
├── security
│      ├── RBAC
│      ├── Network Policy
│      ├── IRSA
│      └── Resource Quota
│
└── shared-services
       ├── Monitoring
       ├── Logging
       ├── Security
       └── Backup

Every tenant operates independently while platform services remain centrally managed.

Enterprise Example

A multinational bank hosts more than 300 applications in Amazon EKS.

Tenant structure:

Retail Banking

Corporate Banking

Payments

Fraud Detection

Customer Portal

Risk Management

Security Operations

Security controls include:

Namespace isolation
RBAC
Network Policies
IRSA
Resource Quotas
Pod Security Standards
AWS WAF
GuardDuty
CloudTrail
AWS Config

This enables secure multi-team collaboration while maintaining regulatory compliance.

Common Multi-Tenant Security Risks

Cloud Security Engineers frequently identify:

Shared Namespaces
Excessive RBAC permissions
Missing Network Policies
Shared Service Accounts
Shared Secrets
No Resource Quotas
Privileged containers
Default Service Accounts
Cross-namespace communication
Shared IAM Roles

These issues can lead to lateral movement and data exposure.

Enterprise Monitoring

Security teams should continuously monitor:

Namespace creation
Namespace deletion
RBAC changes
Network Policy updates
Cross-namespace communication
Service Account changes
Resource Quota violations
Privileged Pod creation
IRSA activity
Tenant resource usage

Monitoring helps identify isolation failures and unauthorised activity.

Zero Trust in Multi-Tenant Kubernetes

Enterprise Kubernetes platforms increasingly adopt a Zero Trust approach.

Core principles include:

Never trust by default
Verify every identity
Enforce least privilege
Restrict east-west traffic
Continuously monitor workloads
Assume breach

Example:

Tenant A

↓

Authentication

↓

RBAC

↓

Network Policy

↓

Pod Security

↓

AWS IAM

↓

Access Granted

Each request is evaluated independently before access is allowed.

Real-World Scenario

A SaaS company hosts multiple customers in a shared Amazon EKS cluster.

Due to missing Network Policies, a compromised application in Customer A’s Namespace scans the cluster and successfully connects to Customer B’s database service.

The attacker:

Enumerates internal services
Attempts credential theft
Accesses sensitive customer information

Following the incident, the company implements:

Namespace isolation
Default deny Network Policies
Dedicated Service Accounts
IRSA
Resource Quotas
Pod Security Standards

These controls prevent lateral movement between tenants and significantly improve the platform’s security posture.

Best Practices

As a Kubernetes Security Engineer:

Isolate every tenant using dedicated Namespaces.
Implement RBAC with the Principle of Least Privilege.
Apply default deny Network Policies.
Use dedicated Service Accounts for every application.
Implement IAM Roles for Service Accounts (IRSA).
Configure Resource Quotas and Limit Ranges.
Enforce Pod Security Standards.
Separate shared platform services from tenant workloads.
Monitor tenant activity continuously.
Perform regular access and configuration reviews.

A secure multi-tenant architecture protects individual workloads while enabling efficient use of shared Kubernetes infrastructure.

Key Takeaways

After completing this lesson, you should understand:

What Kubernetes multi-tenancy is
The difference between soft and hard multi-tenancy
How Namespaces isolate tenants
How RBAC enforces tenant permissions
Why Network Policies are essential
The importance of Resource Quotas and Limit Ranges
How Pod Security Standards strengthen isolation
Common multi-tenant security risks
Enterprise best practices for building secure shared Kubernetes platforms

Multi-tenant security is a core capability of Amazon EKS and Kubernetes. When properly implemented, it allows organisations to securely operate shared clusters while maintaining strong isolation, compliance, and operational efficiency.

Knowledge Check

Question 1

What is the primary purpose of Kubernetes multi-tenancy?

A. Increase Pod scheduling speed
B. Allow multiple independent tenants to securely share the same Kubernetes cluster
C. Replace Kubernetes RBAC
D. Encrypt Kubernetes Secrets

Answer: B

Question 2

Which Kubernetes feature provides the first layer of logical isolation between tenants?

A. ReplicaSets
B. Namespaces
C. ConfigMaps
D. Storage Classes

Answer: B

Question 3

Which Kubernetes feature controls communication between workloads in different Namespaces?

A. Service Accounts
B. Network Policies
C. ConfigMaps
D. Deployments

Answer: B

Question 4

Which feature prevents one tenant from consuming excessive CPU, memory, or Pod resources?

A. Resource Quotas
B. Ingress Controllers
C. ReplicaSets
D. Secrets

Answer: A

Question 5

Which of the following is considered an enterprise best practice for multi-tenant Kubernetes environments?

A. Use a shared Service Account for all applications.
B. Disable RBAC to simplify administration.
C. Create dedicated Namespaces, Service Accounts, Network Policies, and IRSA roles for each tenant.
D. Allow unrestricted communication between all Namespaces.

Answer: C

What’s Next?

In the next lesson, you will learn about Enterprise Access Governance, exploring how organisations implement governance, access reviews, privileged access management (PAM), audit logging, compliance controls, and identity lifecycle management across Amazon EKS environments.

➡️ Next Lesson: Lesson 10 — Enterprise Access Governance