gke-multitenancy

GKE Multi-Tenancy

This reference covers enterprise multi-tenancy patterns on GKE, including namespace isolation, RBAC planning, resource quotas, and network segmentation.

MCP Tools: apply_k8s_manifest, get_k8s_resource, check_k8s_auth, describe_k8s_resource, delete_k8s_resource

When to Use

• Multiple teams sharing a single GKE cluster
• Isolating workloads by environment (dev/staging/prod) within one cluster
• Implementing least-privilege access control
• Cost allocation across teams or projects

Multi-Tenancy Models

Model	Isolation	Complexity	Cost
Namespace-per-team	Soft (RBAC +	Low	Lowest (shared
: : Network : : cluster) :
: : Policy) : : :
Namespace-per-environment	Soft	Low	Low
Node pool-per-team	Medium	Medium	Medium
: : (dedicated : : :
: : compute) : : :
Cluster-per-team	Hard (full	High	Highest
: : isolation) : : :

Golden path recommendation: Start with namespace-per-team for cost efficiency. Escalate to stronger isolation only when compliance requires it.

Namespace Isolation Setup

1. Create Namespaces

kubectl create namespace team-a
kubectl create namespace team-b
kubectl label namespace team-a team=a
kubectl label namespace team-b team=b

2. RBAC Configuration

Principle: Grant minimal permissions per namespace. Never bind to system:authenticated.

# Namespace-scoped role for a team
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-a-developer
  namespace: team-a
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["pods", "deployments", "services", "configmaps", "jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-developers
  namespace: team-a
subjects:
- kind: Group
  name: "[email protected]"  # Google Group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: team-a-developer
  apiGroup: rbac.authorization.k8s.io