A single shared Kubernetes cluster is dramatically cheaper and simpler to operate than one cluster per team, which is why most platform teams converge on multi-tenancy within their first few years at scale. But the cost saving only survives if isolation is deliberate. Kubernetes gives you namespaces as the natural tenant boundary, yet a namespace by itself is only folder-level scoping of resource names. Without RBAC, quotas, network policy, and a Pod security baseline applied consistently across those namespaces, any compromised or careless tenant can degrade or escape into its neighbors. This guide maps each control to a concrete namespace layout so you can share one GKE cluster safely between teams or customers.
The reference model in this guide is soft multi-tenancy, where teams or customers share a control plane but remain isolated by policy. It is the pattern the Kubernetes documentation describes for most organizations, and it is the one GKE supports out of the box with namespaces, RBAC, and network policy. For workloads that must never trust one another, the Kubernetes multi-tenancy overview explains the harder boundaries, up to dedicated clusters or virtual control planes, and when each one is justified.
Namespace-per-tenant as the unit of isolation
Make one namespace per tenant and, ideally, one namespace per workload operated by that tenant. Kubernetes documentation recommends a namespace for each workload even inside a single team, because that gives every workload its own identity and lets you attach a tailored security policy to it. Namespace names should be globally unique across the fleet even if the namespaces live in different clusters; this keeps DNS addresses like checkout.prod.svc.cluster.local unambiguous and leaves room to move a workload to a dedicated cluster later without renaming anything.
What a namespace does and does not isolate
A namespace scopes resource names and, importantly, scopes the policies that Kubernetes applies on top: RBAC Roles and RoleBindings, Network Policies, and ResourceQuotas and LimitRanges are all namespace-scoped. What a namespace does not do is separate nodes, the Linux kernel, or the control plane. Pods from different namespaces can still land on the same node and share its kernel and memory, so namespace isolation is a policy boundary, not a hard security boundary. Treat it as the flexible, low-overhead first layer and add explicit controls on top.
Quotas and limits against noisy neighbors
The quietest way for one tenant to hurt others is to consume the control plane or node capacity without a limit. ResourceQuota caps CPU and memory and the number of objects a namespace can create, which is exactly how Kubernetes documents preventing noisy-neighbor problems and API overload. Enforce a quota on every tenant namespace before granting access, and mirror it with LimitRanges so that workloads always carry requests and limits rather than inheriting no bounds at all.
A minimal quota for a production tenant namespace looks like this, and pairs with the resource guidance in the Secpros GKE cost optimization guide to keep shared capacity fair and billed predictably:
apiVersion: v1 kind: ResourceQuota metadata: name: tenant-quota namespace: acme-prod spec: hard: requests.cpu: 20 requests.memory: 40Gi limits.cpu: 40 limits.memory: 80Gi pods: 60 services: 30 persistentvolumeclaims: 10
RBAC boundaries, not just IAM roles
Control-plane isolation is the highest-leverage control, because anyone who can modify API resources can disable every other policy. On Google Cloud, IAM grants a user access to a cluster and to Kubernetes resources; RBAC then narrows that access to specific namespaces and verbs. The GKE multi-tenancy model keeps this split explicit: a cluster admin owns the cluster, namespace admins own their tenant namespaces, and developers hold namespaced Roles that let them work with Pods, Deployments, and Services only inside their own namespace.
Avoid ClusterRoleBindings for tenant users. Even a service account that needs to read Workload Identity or secrets is better scoped through namespace Roles and a single Workload Identity binding. The Secpros least-privilege RBAC guide covers the Role and RoleBinding design in detail, and the Workload Identity hardening guide shows how to bind a tenant service account to the smallest Google Cloud identity it needs.
Network policy: close east-west traffic by default
Inside a namespace, traffic is unrestricted; between namespaces it must be explicitly allowed. That default is only enforced if you install a network policy controller and actually write policies. A strong starting point for shared clusters is a deny-by-default NetworkPolicy per tenant namespace that permits only the specific ingress and egress peers a workload needs, blocking one compromised namespace from reaching databases or Services in another.
A per-namespace baseline that denies inbound traffic unless a sibling policy allows it is:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-ingress-by-default namespace: acme-prod spec: podSelector: {} policyTypes: - Ingress
Deeper selector, label, and peer examples are in the Secpros network policies guide. Treat network policy as a per-tenant review item, not a one-time flag, because teams rarely keep their dependencies static.
Workload isolation with Pod Security Standards
A namespace boundary is only as strong as the workloads running inside it. Enforce the Kubernetes Pod Security Standards at a baseline or restricted level on every tenant namespace so a tenant cannot run a privileged container, mount the host filesystem, or escalate to root from inside its own namespace. Seeing the Pod Security Standards to restricted also encodes that a namespace boundary is soft; the tighter you make each workload, the less a neighbor breach can reach you.
Operational readiness checklist
- Every tenant names its own namespace, and no workload runs in the default namespace.
- Each tenant namespace has a ResourceQuota and LimitRange before it is shared with a team.
- Tenant users hold namespaced Roles and RoleBindings only; no ClusterRoleBinding for developers.
- A deny-by-default NetworkPolicy exists in every tenant namespace and is reviewed on each dependency change.
- Pod Security Standards are enforced per namespace (baseline or restricted) with an admission controller.
- Workload Identity scopes a tenant service account to its own namespace and GCP project, never cluster-admin.
- Namespaces are globally unique across the fleet so workloads can move to dedicated clusters without renaming.
Start with one namespace-per-tenant on a pilot team, apply the full control stack above, and only expand once the pattern is enforced by policy rather than by habit. The controls here are the same building blocks as a zero-trust platform, and they compose with the RBAC, network policy, and Pod Security work you may already have done.
If you are about to let a second team or a customer onto a shared GKE cluster, Secpros can review your namespace layout, RBAC bindings, quotas, and network policy and return a short, prioritized isolation plan before that shared boundary goes live.