Gke Multitenancy
GoogleOfficialPublished by Google
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured approach to sharing GKE clusters among multiple teams or environments. It details essential isolation techniques including namespace segmentation, RBAC planning, resource management via quotas and limits, and network policy enforcement. It also covers cost allocation strategies to ensure visibility into resource consumption across different organizational units.
What it does
- Defines patterns for namespace-based multi-tenancy in GKE.
- Provides templates for RBAC roles and bindings to enforce least-privilege access.
- Configures ResourceQuotas and LimitRanges to prevent resource exhaustion.
- Implements network isolation using Kubernetes NetworkPolicies.
- Enables GKE cost allocation for granular billing reports by namespace.
- Outlines models for scaling isolation from shared namespaces to dedicated clusters.
When to use it
- When multiple teams need to share a single GKE cluster securely.
- When isolating workloads between development, staging, and production environments.
- When implementing least-privilege access control for cluster resources.
- When you need to track and attribute infrastructure costs to specific teams or projects.
Advantages
- Improves cost efficiency by maximizing shared cluster resource utilization.
- Enhances security posture through namespace isolation and RBAC.
- Prevents noisy neighbor issues with resource quotas and limits.
- Provides clear paths for scaling isolation based on compliance requirements.
Usage examples
- “How do I set up a new team namespace in GKE with resource limits?”
- The agent will provide commands to create the namespace and apply a ResourceQuota and LimitRange manifest to ensure the team stays within defined resource boundaries.
- “Help me restrict a team's access to only their own namespace.”
- The agent will generate a Role and RoleBinding configuration that restricts the team's permissions to a specific namespace using Google Groups.
- “How can I track GKE costs by team?”
- The agent will guide you through labeling namespaces by cost center and enabling the GKE cost allocation feature via the gcloud CLI.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/google/gke-multitenancy/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip gke-multitenancy.zip -d .agents/skills
Documentation by Google
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=b2. 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.ioRBAC 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
minormaxlimits in aLimitRange, you must also define correspondingdefaultanddefaultRequestvalues. If you set aminormaxwithout 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: 53Cost 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-scienceGKE Cost Allocation
Enable GKE cost allocation to break down costs by namespace and label:
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
--enable-cost-allocationView in Cloud Billing > GKE Cost Allocation.
Files
- ATTRIBUTION.mdAdded by AutoGineer850 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md5.7 KiB
- references/attribution.md1.8 KiB
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs a command-line tool
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Publisher
- Google (Official)
- Source
- google/skills · skills/cloud/gke-multitenancy · commit 2194d3b
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Google or Google.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download gke-multitenancy.zip