Home/Cloud & Infrastructure/gke-multitenancy
G

gke-multitenancy

by @googlev
4.5(120)

This skill automates the configuration and management of multi-tenancy patterns on GKE, including namespace isolation, RBAC planning, resource quotas, and network segmentation. It helps teams achieve secure isolation, cost allocation, and least-privilege access on shared clusters, reducing operational complexity.

kubernetesgkemulti-tenancyrbacresource-quotasGitHub
Installation
npx skills add https://github.com/google/skills --skill gke-multitenancy
compare_arrows

Before / After Comparison

1 组
Before

Without this skill, teams manually create namespaces, RBAC, and network policies, taking about 2 hours per tenant with risks of privilege leaks or resource contention.

After

This Skill automates standard multi-tenant configurations via templates and scripts, reducing setup time to 15 minutes per tenant and embedding security best practices.

SKILL.md

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

ModelIsolationComplexityCost
Namespace-per-teamSoft (RBAC +LowLowest (shared
: : Network : : cluster) :
: : Policy) : : :
Namespace-per-environmentSoftLowLow
Node pool-per-teamMediumMediumMedium
: : (dedicated : : :
: : compute) : : :
Cluster-per-teamHard (fullHighHighest
: : 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 Cloud Billing > GKE Cost Allocation.

User Reviews (0)

Write a Review

Effect
Usability
Docs
Compatibility

No reviews yet

Statistics

Installs6.4K
Rating4.5 / 5.0
Version
Updated2026年10月23日
Comparisons1

User Rating

4.5(120)
5
37%
4
43%
3
13%
2
5%
1
2%

Rate this Skill

0.0

Compatible Platforms

🤖claude-code

Timeline

Created2026年7月26日
Last Updated2026年10月23日
🎁 Agent Knowledge Cards
Survey