> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi Tenancy Made Practical Models Tradeoffs Guardrails Part 1

> Practical guide to Kubernetes multi tenancy guardrails using namespaces, RBAC, ResourceQuotas, NetworkPolicies and Pod Security Standards to limit blast radius, enforce least privilege, and ensure fair resource usage.

In this lesson we examine the guardrail stack: the practical mechanisms you configure to make Kubernetes safe for multi-tenancy in production. Think of it as a five-layer defense where each layer addresses a different concern. Use these guardrails together — individually none is sufficient for production multi-tenancy.

Quick summary

* Goal: reduce blast radius, enforce least privilege, and ensure fair resource usage across tenants.
* Scope: cluster-scoped controls and namespace-scoped controls combined.
* Recommended: apply Namespaces, RBAC, ResourceQuotas, NetworkPolicies, and Pod Security Standards together.

What the stack looks like (high level)

| Layer | Purpose | Typical scope |
| - | - | - |
| Namespaces | Logical isolation and naming boundary | Namespace |
| RBAC (Roles / ClusterRoles) | Access control: who can do what | Namespace / Cluster |
| ResourceQuotas | Fairness and resource limits | Namespace |
| NetworkPolicies | Pod-to-pod network segmentation | Namespace / Pod |
| Pod Security Standards | Workload hardening (runtime constraints) | Namespace / Pod via admission |

For detailed references:

* [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
* [Kubernetes NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
* [Pod Security Admission Controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/)

The guardrail layers (bottom → top)

Namespaces

* Provide logical isolation and a naming boundary that separates resources for different teams, applications, or environments.
* They are the foundation for the rest of the guardrail stack.
* Most guardrails are applied at the namespace level; some controls (for example ClusterRoles/ClusterRoleBindings or cluster-scoped admission controllers) operate at cluster scope.

Role-Based Access Control (RBAC)

* Controls who can do what inside a namespace (and at cluster scope when using ClusterRoles/ClusterRoleBindings).
* Define Roles or ClusterRoles that list allowed verbs on resources, and RoleBindings to assign those Roles to users or service accounts.
* RBAC answers: can this user or service account perform this action on this resource in this namespace?

ResourceQuotas

* Cap total resource consumption per namespace: CPU, memory, storage, and counts of Kubernetes objects (pods, services, ConfigMaps, secrets, etc.).
* Enforce fairness so a single namespace cannot starve others.
* Treat ResourceQuotas as hard limits on requested resources and object counts — they prevent creating new objects or requests that would exceed the quota.
* Note: runtime enforcement of CPU/memory consumption is handled by LimitRanges, container runtimes, cgroups, and eviction behavior; quotas govern requested resources and counts.

NetworkPolicies

* Act as pod-to-pod firewall rules to restrict network communication.
* Kubernetes treats NetworkPolicy as opt-in: if no policy selects a pod, traffic is typically allowed. Apply policies to create deny-by-default behavior and explicitly permit required flows.
* Example use case: allow only frontend pods to reach backend pods on TCP/8080.

```yaml theme={null}
# Example NetworkPolicy: allow frontend namespace to talk to backend pods on TCP/8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend-8080
  namespace: backend
spec:
  podSelector: {}        # select all backend pods
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - protocol: TCP
      port: 8080
```

Pod Security Standards

* Replaces the older PodSecurityPolicy model and is enforced via the Pod Security Admission controller (and other policy engines like OPA/Gatekeeper).
* Prevents workloads from performing dangerous operations such as:
  * running as root,
  * using privileged mode,
  * mounting host filesystems,
  * binding to the host network.
* Three policy levels:
  * Privileged — allows everything (least restrictive).
  * Baseline — sensible defaults for general workloads.
  * Restricted — strict settings for high-security workloads.

Each layer addresses a distinct constraint:

* Namespaces: logical isolation and naming boundaries.
* RBAC: who may perform which actions.
* ResourceQuotas: fairness and resource limits.
* NetworkPolicies: network segmentation and least privilege network flows.
* Pod Security Standards: workload hardening and attack surface reduction.

Alone, each layer is incomplete — together they form a practical, defensible multi-tenancy model.

![A colorful stacked-ring diagram titled "The Guardrails Stack" that illustrates layers of Kubernetes isolation and security controls. Each ring is labeled (Namespaces, RBAC, ResourceQuotas, NetworkPolicies, Pod Security Standards) with brief descriptions like logical isolation, access control, and workload hardening.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Multi-Tenancy-Made-Practical-Models-Tradeoffs-Guardrails-Part-1/guardrails-stack-kubernetes-security-diagram.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=46bb96b8f15f58a06e0563753e61bdd6)

Designing namespaces

Namespace naming and structure may seem trivial, but they affect RBAC, quotas, monitoring, billing, and operational tooling. Choose a naming and partitioning pattern that aligns with your organizational model and enforce it consistently.

Common namespace design patterns:

| Pattern | Example namespace names | Pros | Cons |
| - | - | - | - |
| By team | `team-payments`, `team-checkout`, `team-inventory` | Clear ownership; straightforward RBAC mapping | Cross-team applications can be hard to place |
| By environment | `dev`, `staging`, `production` | Simple mental model; environment-wide policies are easy | A single env namespace can become crowded |
| By app + environment | `payments-dev`, `payments-prod` | Granular isolation for quotas, RBAC, and NetworkPolicies | Namespace sprawl (e.g., many apps × environments) |

Recommendation: for most organizations either the by-team pattern or by-app-plus-environment pattern works well. Consistency is the most important property — pick a pattern and enforce it.

Enforcement techniques

* Use validating admission webhooks or automation to prevent teams from creating namespaces that break your policy.
* Automate namespace lifecycle and labeling to ensure tools (billing, monitoring, security) can rely on predictable metadata.

Automate namespace creation with templates that include standard labels, ResourceQuotas, LimitRanges, NetworkPolicies, and Pod Security labels. This reduces drift and ensures guardrails are applied consistently.

![A presentation slide titled "Namespace Design Patterns" showing three columns—By Team, By Environment, and By App + Environment—with example namespace names (e.g., team-payments, dev, payments-prod) and small plus/minus pros-and-cons. A footer note advises choosing based on organizational structure and isolation requirements.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Multi-Tenancy-Made-Practical-Models-Tradeoffs-Guardrails-Part-1/namespace-design-patterns-team-environment-app.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=2698a51e110c44a6f05804dfe4b1f32a)

Takeaways

Kubernetes is not multi-tenant by default. Design and apply multiple guardrails to achieve safe multi-tenancy in production.

1. Kubernetes is not multi-tenant by default — this is the single most important point.
2. Soft vs. hard multi-tenancy is determined by how much you trust tenants:
   * Trusted tenants: soft multi-tenancy with strict guardrails can be cost-effective.
   * Untrusted tenants: prefer stronger isolation (separate clusters, VMs, or stricter policies).
3. Layer your guardrails — no single mechanism provides complete isolation. Use Namespaces, RBAC, ResourceQuotas, NetworkPolicies, and Pod Security Standards together.
4. Consistent namespace naming matters. Choose a pattern and enforce it with admission controllers and automation.

Next steps

* Dive deeper into ResourceQuotas + LimitRanges to create practical quota policies and patterns for fair resource allocation.
* Explore admission controllers (validating and mutating webhooks) and OPA/Gatekeeper for custom policy enforcement.
* Review Pod Security Admission labels and how to migrate workloads across Pod Security levels.

Further reading and references

* [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
* [Kubernetes NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
* [Pod Security Admission controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
* [ResourceQuotas and LimitRanges](https://kubernetes.io/docs/concepts/policy/resource-quotas/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/989346de-0207-4837-af11-bf456d188972/lesson/901ef40f-2185-40ab-932c-e93ea999181b)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.