Namespace Isolation
Kubernetes namespace isolation is the infrastructure-level boundary that prevents one tenant's workloads from accessing another tenant's compute, network, and storage resources. Each tenant receives a dedicated namespace with NetworkPolicies, ResourceQuotas, RBAC bindings, and Pod Security Standards.
Per-Tenant Namespaces
In production, each tenant receives a dedicated Kubernetes namespace:
| Pattern | Example |
|---|---|
matih-data-plane-{tenant-slug} | matih-data-plane-acme-corp |
Each namespace is a complete security boundary containing all Data Plane services, secrets, and configuration for that tenant.
Namespace Security Controls
| Control | Purpose | Enforcement |
|---|---|---|
| NetworkPolicy | Block cross-namespace traffic | Kubernetes CNI (Calico/Cilium) |
| ResourceQuota | Limit CPU, memory, pod count | Kubernetes scheduler |
| LimitRange | Default and max per-pod limits | Kubernetes admission controller |
| RBAC | Restrict API access to own namespace | Kubernetes API server |
| PodSecurityStandards | Enforce non-root, read-only FS | Kubernetes admission controller |
| ServiceAccount | Least-privilege identity | Kubernetes RBAC bindings |
NetworkPolicy
Each tenant namespace has a default-deny policy with explicit allowlist:
Allowed Ingress
| Source | Purpose |
|---|---|
| Pods within the same namespace | Internal service communication |
| Control Plane namespace | Management and health checks |
| Tenant's ingress controller | External traffic via tenant domain |
Allowed Egress
| Destination | Purpose |
|---|---|
| Pods within the same namespace | Internal service communication |
| Shared infrastructure namespace | PostgreSQL, Redis, Kafka |
| Kubernetes DNS (port 53/UDP) | Name resolution |
Blocked
| Traffic Pattern | Status |
|---|---|
| Tenant A to Tenant B namespace | Blocked |
| Tenant to Control Plane (except allowed paths) | Blocked |
| Direct internet egress | Blocked |
ResourceQuota by Tier
| Resource | Free | Professional | Enterprise |
|---|---|---|---|
requests.cpu | 2 | 8 | Custom |
requests.memory | 4Gi | 16Gi | Custom |
limits.cpu | 4 | 16 | Custom |
limits.memory | 8Gi | 32Gi | Custom |
pods | 20 | 50 | Custom |
services | 10 | 20 | Custom |
persistentvolumeclaims | 5 | 10 | Custom |
RBAC Bindings
Each tenant namespace has a dedicated ServiceAccount:
| Permission | Scope |
|---|---|
get, list pods | Own namespace only |
get, list services | Own namespace only |
get secrets | Own namespace only |
get, list configmaps | Own namespace only |
The ServiceAccount cannot access resources in other namespaces.
Pod Security
| Standard | Enforcement |
|---|---|
| Run as non-root | Required |
| Read-only root filesystem | Enabled where supported |
| Privilege escalation | Disabled |
| Host network access | Disabled |
| Host PID namespace | Disabled |
| Capabilities | Drop ALL, add only NET_BIND_SERVICE if needed |
Namespace Provisioning
During tenant provisioning (Phase 2), the following resources are created:
| Resource | Created By |
|---|---|
| Namespace | Tenant Service via Infrastructure Service |
| NetworkPolicy | Infrastructure Service |
| ResourceQuota | Infrastructure Service (tier-based) |
| LimitRange | Infrastructure Service |
| ServiceAccount | Infrastructure Service |
| RoleBinding | Infrastructure Service |
Monitoring
| Signal | Detection Method |
|---|---|
| NetworkPolicy violations | CNI plugin flow logs |
| ResourceQuota exhaustion | Prometheus kube_resourcequota metrics |
| Pod security violations | Kubernetes audit logs |
| Cross-namespace attempts | Kubernetes API server audit |
Related Pages
- Database Isolation -- Schema-level data isolation
- Resource Isolation -- CPU/memory quota details
- Tenant Context Propagation -- Application-level context
- Architecture: Namespace Isolation -- Architecture perspective