Kubernetes Multi-Tenancy: Namespace, RBAC, and Quota Design

Multi-tenancy in Kubernetes is a design problem across identity, resource isolation, and operational ownership. Most failures happen when teams share clusters without explicit boundaries.

1. Choose Your Tenancy Model

Common models:

  • soft multi-tenancy: namespaces as team boundaries in one cluster
  • hard multi-tenancy: dedicated clusters per tenant
  • hybrid: shared cluster for low-risk workloads, dedicated clusters for regulated workloads

Choose based on compliance, risk tolerance, and operational budget.

2. Namespace Strategy

Use predictable namespace naming:

  • team-a-dev
  • team-a-staging
  • team-a-prod

Avoid mixing multiple environments in one namespace.

3. RBAC Design Principles

  • grant access by group, not by individual user
  • separate read-only, operator, and admin roles
  • avoid wildcard verbs/resources in shared clusters

Example role pattern:

  • team-editor: manage workloads in namespace
  • team-viewer: read logs and resources
  • platform-admin: cluster-level operations

4. Resource Quotas and Limits

Without quotas, one team can starve others.

Apply both:

  • ResourceQuota for namespace-level caps
  • LimitRange for default and max per pod/container
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a-prod
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    pods: "200"

5. Network Isolation

Default deny traffic between namespaces and allow only required flows.

At minimum:

  • deny cross-namespace ingress by default
  • allow ingress from approved gateways and dependencies
  • control egress to internet and data systems

6. Tenant-Aware Observability

Each tenant should have:

  • namespace-level dashboards
  • cost and usage visibility
  • alert routing to correct team
  • audit trail for privileged actions

7. Platform Guardrails

Enforce baseline policies for every tenant namespace:

  • mandatory labels (team, env, owner)
  • requests/limits required
  • restricted pod security level
  • trusted image registries only

8. Day-2 Operations Checklist

  • monthly RBAC access review
  • quota tuning based on real usage
  • namespace lifecycle management and cleanup
  • incident postmortems with cross-tenant impact review
  1. team-per-namespace-per-environment
  2. group-based RBAC
  3. quota + limit range on every tenant namespace
  4. default deny network policy
  5. policy enforcement for workload standards

This baseline keeps shared clusters secure and predictable without overcomplicating operations.