gke-multitenancy

Files (2)

• SKILL.md
• attribution.md · references/

SKILL.md (first lines)

# 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](references/attribution.md). 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

```bash
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`.

```yaml
# 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:

```yaml
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:

```yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a

From google/skills, Apache-2.0.

More from google/skills