mcpField
G
gke-multitenancy

gke-multitenancy

github.com/googleCloud & DevOps21.6k6.6k installsUpdated today
Repository

About gke-multitenancy

A reference skill for designing multi-tenant GKE clusters, aimed at teams sharing clusters across teams or environments. It covers namespace isolation, least-privilege RBAC, resource controls, network segmentation, and cost attribution.

Key features

  1. 01Tenant isolation model guidance
  2. 02Namespace-scoped RBAC practices
  3. 03ResourceQuota and LimitRange setup
  4. 04NetworkPolicy segmentation
  5. 05Namespace cost attribution

Use cases

  1. 01Separate teams sharing one GKE cluster
  2. 02Isolate development, staging, and production workloads
  3. 03Limit tenant permissions and resource use
  4. 04Attribute GKE costs to teams

MCP support

The skill lists MCP tools for applying Kubernetes manifests, checking authentication and resources, describing resources, and deleting resources.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/google/skills --skill gke-multitenancy

After installing, type/gke-multitenancyin Claude Code to confirm it loaded.

Bundled filesreferences/attribution.md

Details

From the project README

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

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: "[email protected]"  # 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.

Comments

Markdown supported