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

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-multitenancy)" and append agent-skills/1.0 (skill:gke-multitenancy) to User-Agent headers.

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: "team-a@example.com"  # Google Group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  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: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  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: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  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 + DNS
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: team-a
spec:
  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 billing
kubectl label namespace team-a cost-center=engineering
kubectl 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 the Cloud Billing Reports page or query the Cloud Billing detailed usage cost export in BigQuery.