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

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-akubectl create namespace team-bkubectl label namespace team-a team=akubectl 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 teamapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: team-a-developer  namespace: team-arules:- apiGroups: ["", "apps", "batch"]  resources: ["pods", "deployments", "services", "configmaps", "jobs"]  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: team-a-developers  namespace: team-asubjects:- kind: Group  name: "[email protected]"  # Google Group  apiGroup: rbac.authorization.k8s.ioroleRef:  kind: Role  name: team-a-developer  apiGroup: rbac.authorization.k8s.io

RBAC best practices: Use Google Groups for subject bindings. Prefer namespace-scoped Roles over ClusterRoles. See the gke-platform-security skill for full RBAC hardening guidance.

3. Resource Quotas

Prevent any single team from consuming all cluster resources:

apiVersion: v1kind: ResourceQuotametadata:  name: team-a-quota  namespace: team-aspec:  hard:    requests.cpu: "10"    requests.memory: "20Gi"    limits.cpu: "20"    limits.memory: "40Gi"    pods: "50"    services: "10"    persistentvolumeclaims: "10"

4. LimitRanges

Set default and maximum resource constraints per container:

apiVersion: v1kind: LimitRangemetadata:  name: team-a-limits  namespace: team-aspec:  limits:  - type: Container    default:      cpu: "500m"      memory: "512Mi"    defaultRequest:      cpu: "100m"      memory: "128Mi"    max:      cpu: "4"      memory: "8Gi"

[!IMPORTANT] Mandatory Defaults: When defining min or max limits in a LimitRange, you must also define corresponding default and defaultRequest values. If you set a min or max without defaults, any pod deployed without explicit resource requests/limits will be rejected by the admission controller.

5. Network Isolation

Apply default-deny per namespace (see the gke-workload-security skill), then allow intra-team traffic:

# Allow same-namespace pods to talk + DNSapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: allow-same-namespace  namespace: team-aspec:  podSelector: {}  ingress:  - from:    - podSelector: {}  egress:  - to:    - podSelector: {}  - to:  # Allow DNS    - namespaceSelector: {}      podSelector:        matchLabels:          k8s-app: kube-dns    ports:    - protocol: UDP      port: 53

Cost Allocation

Labels for Cost Attribution

# Label namespaces for billingkubectl label namespace team-a cost-center=engineeringkubectl label namespace team-b cost-center=data-science

GKE Cost Allocation

Enable GKE cost allocation to break down costs by namespace and label:

gcloud container clusters update <CLUSTER_NAME> --region <REGION> \  --enable-cost-allocation

View in Cloud Billing > GKE Cost Allocation.