Rancher Project Multi-Tenancy: One Cluster, Multiple Teams

Requirement: one cluster, multiple teams

A platform team operates one Rancher-managed downstream Kubernetes cluster. Several development teams need to deploy workloads on it, but the platform team must prevent one team from consuming all CPU and memory, and must block accidental network traffic between teams. Provisioning a separate cluster for every team increases cost and operational overhead, so the goal is logical isolation inside a single cluster.

Smallest suitable design

Create one Rancher Project per team. A Project is a Rancher grouping of one or more Kubernetes namespaces inside a single cluster. Map each team's namespaces into its project. Apply a Kubernetes ResourceQuota to each namespace to bound CPU and memory requests and limits. Enable Rancher project network policies and configure a default deny rule for traffic between projects, while permitting traffic inside a project.

Trust and data boundaries

The Rancher server and its authentication backend are trusted control-plane components. Project members are trusted only within their project scope. A cluster administrator retains full access and can bypass project restrictions. Projects are not a security boundary for untrusted or hostile workloads; a compromised pod with cluster-scoped permissions can escape project limits.

Operational checks

• Verify quota usage in the Rancher dashboard under Cluster > Project > Resource Quotas.
• Audit network policy enforcement by deploying test pods in two projects and attempting cross-project connectivity.
• Review project membership changes in the Rancher audit log.
• Confirm the installed Rancher version supports project network policies before relying on them in production.

Failure modes

• Quota exhaustion leaves new pods Pending with failed scheduling events.
• Misconfigured network policies break intra-service communication, even between services in the same project.
• Deleting a project can orphan namespaces, depending on the Rancher version.
• Stale RBAC bindings can retain access for removed members until bindings are reconciled.

Conditions that change the design

If teams require cluster-scoped resources such as CustomResourceDefinitions or storage classes, project quotas do not control them. If compliance or threat modeling requires strict node-level isolation or separate control planes, move to separate clusters managed through Rancher Multi-Cluster Management instead of projects.

Verification example

Run the following from a workstation with a kubeconfig pointed at the downstream cluster. You need cluster-admin or project-owner permissions. Replace placeholders in angle brackets with your cluster and namespace names.

kubectl get namespace -A

kubectl apply -f quota.yaml

kubectl describe resourcequota team-quota -n <team-namespace>

kubectl run test-a --image=busybox -n <project-a-namespace> --restart=Never -- sleep 3600
kubectl run test-b --image=busybox -n <project-b-namespace> --restart=Never -- sleep 3600

kubectl exec test-a -n <project-a-namespace> -- wget --timeout=3 <test-b-service-ip>:80

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: <team-namespace>
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

Expected checks: the quota description shows used versus hard limits; cross-project wget times out or is refused; intra-project wget succeeds. Risks: a deny-all network policy can break existing service discovery before exceptions are added, and a quota set too low blocks legitimate deployments.

Limitations

Resource quotas are enforced at the namespace level, not as a single project-wide aggregate in all Rancher versions. Cluster-scoped resources are not controlled by project quotas. Behavior for project network policies and namespace migration between projects differs between Rancher versions. Review Rancher release notes for your version before production use.

Practical way to check the result

After applying the quota, attempt to deploy a workload that exceeds the hard limit and confirm the pod stays Pending with a failed scheduling event. After applying the network policy, confirm cross-project traffic is blocked while intra-project traffic still works.