Week 23 - RBAC, Multi-Tenancy, mTLS Everywhere¶

23.1 Conceptual Core¶

Multi-tenancy is the hardest sustained problem in Kubernetes. The kernel and Kubernetes give you soft isolation by default; converting that to hard isolation requires layered controls.
The required layers: namespace-per-tenant + RBAC + NetworkPolicy + ResourceQuota + LimitRange + PodSecurity + node-pool isolation + (optionally) sandboxed runtime.
mTLS everywhere: control-plane (already from week 22), service mesh between Services (week 15), workload identity for Pods talking to cloud APIs (e.g., AWS IRSA, GCP Workload Identity).

Tenant onboarding as code (Crossplane Composition or Helm chart):
Namespace.
ResourceQuota + LimitRange.
Default-deny NetworkPolicy + an allow-namespace-internal exception.
PodSecurity admission label (restricted).
RoleBindings for the tenant's group.
ServiceAccount with workload identity binding for cloud access.
GitOps Application(Set) entries to deploy the tenant's app catalog.
Hard isolation tiers:
Tier 1: namespace + RBAC. Default. Suitable for trusted internal teams.
Tier 2: + sandboxed runtime (gVisor) for tenant-owned untrusted workloads.
Tier 3: + dedicated node pool with taints. Suitable for compliance-bound workloads.
Tier 4: separate cluster (vCluster, Cluster API). Strongest isolation; highest cost.

Author a tenant Composition (Crossplane) or Helm chart that, given {tenant: "acme"}, materializes everything in §23.2.
Onboard acme. Have a "tenant developer" persona deploy an app via GitOps.
Verify isolation: from acme's namespace, can you read another tenant's secrets? Pods? Logs? Each should fail.

Run kubescape or polaris against the cluster. Address findings until score is >90%.

Per-tenant cost attribution: label every resource with tenant=; export kube-state-metrics with that label to Prometheus; cost-allocate via OpenCost.