/gke-multitenancy
Plans and configures multi-tenancy on GKE. Covers namespace isolation, RBAC planning for teams, resource quotas, LimitRanges, network isolation, and cost allocation. Use when designing GKE multi-tenancy, configuring GKE namespaces, setting up resource quotas, or isolating GKE
$ npx -y skills add google/skills --skill gke-multitenancy --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/gke-multitenancy
Context preview
The summary Claude sees to decide when to auto-load this skill.
Plans and configures multi-tenancy on GKE. Covers namespace isolation, RBAC planning for teams, resource quotas, LimitRanges, network isolation, and cost allocation. Use when designing GKE multi-tenancy, configuring GKE namespaces, setting up resource quotas, or isolating GKE
SKILL.md
gke-multitenancy.SKILL.mdname: gke-multitenancy
description: >-
Plans and configures multi-tenancy on GKE. Covers namespace isolation, RBAC
planning for teams, resource quotas, LimitRanges, network isolation, and
cost allocation. Use when designing GKE multi-tenancy, configuring GKE
namespaces, setting up resource quotas, or isolating GKE teams. Don't use
for single-tenant cluster configuration or general deployment instructions
(use gke-basics or gke-app-onboarding instead).
metadata:
category: Containers
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
| 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: 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-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.
Read more
name: gke-multitenancy description: >- Plans and configures multi-tenancy on GKE. Covers namespace isolation, RBAC planning for teams, resource quotas, LimitRanges, network isolation, and cost allocation. Use when designing GKE multi-tenancy, configuring GKE namespaces, setting up resource quotas, or isolating GKE teams. Don't use for single-tenant cluster configuration or general deployment instructions (use gke-basics or gke-app-onboarding instead). metadata: category: Containers
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
| 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: 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-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.
This repository contains Agent Skills for Google products and technologies, including Google Cloud. This repository is under active development.
Repo: google/skills
Other skills on google-skills.
- /data-manager-api-audience-ingestion
Guides developers through managing (adding, removing, and clearing) audience members for Google products using the Data Manager API and its associated client libraries. Use this skill when the user wants to upload audience members, remove specific users, or clear/replace an
Open skill - /data-manager-api-event-ingestion
Guides developers through implementing event and conversion ingestion to Google products using the Data Manager API /v1/events/ingest endpoint and its associated client libraries. Use this skill when the user wants to upload offline conversions, enhanced conversions for leads,
Open skill - /data-manager-api-setup
Guides developers through client library installation and authentication setup steps for the Data Manager API. Use this skill when a user is getting started with the Data Manager API and needs to setup their local environment, install the client library, or setup access to the
Open skill - /google-ads-api-account-diagnostics
Diagnoses Google Ads account performance issues such as conversion loss (value or volume), low lead flow/volume, and lost impression share (opportunities) due to ad rank, bids, or budgets. Use when troubleshooting sudden performance drops, analyzing campaign impression share
Open skill - /google-ads-api-mcp-setup
Guides developers through downloading, configuring, and installing the official open-source Google Ads MCP Server. Use this skill when a user wants to connect their AI assistant (such as Gemini, Claude Code, or Cursor) to their Google Ads account to query campaigns or retrieve
Open skill - /google-ads-api-quickstart
Guides developers through Google Ads API quickstart: credential setup, choosing from 6 client libraries/REST, configuring environments, and running a "retrieve campaigns" script. Troubleshoots common setup errors: USER_PERMISSION_DENIED, login_customer_id issues, and
Open skill

