Kubernetes Multi-Tenancy Setup with Namespace Isolation

## ROLE
You are a Kubernetes platform engineer who builds shared cluster platforms for multiple development teams. You specialize in designing multi-tenant architectures that provide strong isolation between tenants while maintaining operational efficiency and cost sharing.

## OBJECTIVE
Design and implement a multi-tenant Kubernetes cluster configuration where multiple teams can safely share infrastructure with proper resource isolation, security boundaries, and self-service capabilities.

## TASK

**STEP 1: TENANCY MODEL SELECTION**
Define the multi-tenancy approach:
- **Namespace-based (soft multi-tenancy):** Each team gets dedicated namespaces — suitable for teams within the same organization
- **Cluster-based (hard multi-tenancy):** Separate clusters per team — for untrusted tenants or strict compliance
- **Virtual cluster (vCluster):** Virtual Kubernetes clusters within a host cluster — middle ground

For most organizations, recommend namespace-based with strong policies, and explain when to escalate to vCluster or separate clusters.

**STEP 2: NAMESPACE DESIGN**
Create a namespace strategy:
- Naming convention: `<team>-<environment>` (e.g., `team-alpha-dev`, `team-alpha-prod`)
- Standard namespace labels:
  - `team: alpha`
  - `environment: dev|staging|prod`
  - `cost-center: 12345`
  - `pod-security.kubernetes.io/enforce: restricted`

Automated namespace provisioning template:
```yaml
# Namespace + ResourceQuota + LimitRange + NetworkPolicy + RBAC
# All created atomically when onboarding a new team
```

**STEP 3: RESOURCE QUOTAS**
Configure fair resource sharing:
- Per-namespace ResourceQuota:
  - CPU and memory limits (requests and limits)
  - Maximum number of pods, services, PVCs
  - Storage quota per StorageClass
  - Object count limits (ConfigMaps, Secrets)

- Example quota tiers:
  - Small team: 8 CPU, 16Gi memory, 50Gi storage, 20 pods
  - Medium team: 32 CPU, 64Gi memory, 200Gi storage, 100 pods
  - Large team: 128 CPU, 256Gi memory, 1Ti storage, 500 pods

- LimitRange per namespace:
  - Default resource requests and limits for pods without explicit settings
  - Min/max resource constraints per container
  - Prevents resource hogging by individual pods

**STEP 4: RBAC CONFIGURATION**
Design role-based access per tenant:

*Cluster-level roles (managed by platform team):*
- cluster-admin: Full access (platform team only)
- cluster-viewer: Read-only across all namespaces (SRE team)

*Namespace-level roles (per team):*
- namespace-admin: Full access within their namespaces
- namespace-developer: Create/update deployments, services, configmaps; no RBAC changes
- namespace-viewer: Read-only within the namespace

Bind roles using Groups from OIDC provider:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-alpha-developers
  namespace: team-alpha-dev
subjects:
- kind: Group
  name: team-alpha-devs
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-developer
  apiGroup: rbac.authorization.k8s.io
```

**STEP 5: NETWORK ISOLATION**
Implement network boundaries between tenants:
- Default deny-all NetworkPolicy per namespace
- Allow intra-namespace communication
- Explicitly whitelist cross-namespace access (e.g., shared services)
- Separate ingress controllers per tenant or use IngressClass isolation
- DNS policy: Consider restricting cross-namespace DNS resolution

**STEP 6: SHARED SERVICES**
Configure shared platform services accessible to all tenants:
- Monitoring stack (Prometheus with namespace-scoped dashboards)
- Logging pipeline (tenant-specific log streams)
- Ingress controller (shared with per-namespace IngressClass or annotations)
- Cert-manager for automated TLS certificates
- External Secrets Operator with per-namespace secret stores

**STEP 7: TENANT ONBOARDING AUTOMATION**
Create an automated tenant onboarding process:
1. Team requests namespace via GitOps PR (team name, tier, members)
2. CI pipeline validates the request against policies
3. Approved PR triggers creation of: Namespace, ResourceQuota, LimitRange, NetworkPolicy, RBAC bindings, default ServiceAccount
4. Team receives access credentials and namespace documentation
5. Monitoring dashboards auto-provisioned via Grafana templates

**STEP 8: GOVERNANCE & POLICY ENFORCEMENT**
Deploy OPA Gatekeeper or Kyverno policies:
- Enforce resource labels on all objects
- Require resource requests and limits on all containers
- Block privileged containers and host network access
- Enforce image registry whitelist per tenant
- Prevent cross-namespace resource references