Sharing a Kubernetes cluster between teams is usually a cost and operations decision, and it is a reasonable one. The failure mode is that the isolation assumed by the people running workloads is stronger than the isolation the cluster actually provides. A namespace is a naming boundary, not a security or capacity boundary, until it is deliberately made into one.
Decide what tenancy actually means here
Before touching manifests, write down the threat and failure model in a paragraph. Teams inside one company that trust each other but must not be able to exhaust each other's capacity need a very different configuration from workloads handling data with different regulatory treatment, or from anything running untrusted customer code.
- Soft multi-tenancy: cooperating internal teams. Namespaces, quotas, RBAC and network policy are usually sufficient.
- Hard multi-tenancy: differing trust or compliance boundaries. Separate node pools at minimum, frequently separate clusters.
- Untrusted code: separate clusters, or a sandboxed runtime. Do not attempt this with namespaces alone.
The cheapest isolation control is a second cluster. It is worth pricing that honestly before engineering elaborate in-cluster separation that still shares a control plane and a node kernel.
Capacity isolation comes before security isolation
Most real incidents in shared clusters are not attacks; they are one workload consuming the resource everyone else needed. Requests and limits, quotas and priority classes are the controls that prevent that, and they only work if they are enforced rather than recommended.
- 1.Set a ResourceQuota and LimitRange per namespace so unbounded pods cannot be admitted at all.
- 2.Require CPU and memory requests on every workload; admission policy should reject anything without them.
- 3.Use PriorityClasses so platform components are not evicted before application workloads under pressure.
- 4.Reserve headroom on nodes for the kubelet and system daemons; a node that runs out of memory takes unrelated pods with it.
Network policy is default-deny or it is decoration
A cluster without network policy allows every pod to reach every other pod, across every namespace. Adding allow rules to that baseline changes nothing. The only configuration worth deploying starts with a default-deny ingress and egress policy per namespace, then adds the specific flows each workload needs.
- Default-deny both directions per namespace, then allow named flows and DNS explicitly.
- Restrict egress to the internet; exfiltration and accidental dependency on unmanaged endpoints both start there.
- Block access to the cloud instance metadata endpoint from application pods and use workload identity instead.
- Test the policies — a policy that silently matches nothing looks identical to a working one until an audit.
Scope identity and admission tightly
RBAC should be namespace-scoped by default, with cluster-wide roles the rare exception that a human reviews. Pair that with an admission policy layer so that the rules are enforced at creation time rather than discovered in review: no privileged containers, no host networking or host path mounts, non-root users, read-only root filesystems, and images only from approved registries.
Make the boundaries observable
Tenancy that cannot be measured drifts. Per-namespace dashboards for CPU and memory usage against quota, evictions, throttling and policy denials tell platform and application teams the same story, which is what stops these conversations from becoming arguments. Cost allocation by namespace label belongs in the same place.
None of this is exotic Kubernetes. It is a small set of defaults applied consistently at namespace creation, which is why the durable fix is a paved-road namespace template rather than a wiki page describing what teams ought to configure.