Mandantenmodell und Isolation
Wie Tenant-Identity, Namespace-Isolation und Capacity-Boundaries technisch umgesetzt sind.
gh0stcloud-Tenancy ist kein Konvention-basiertes Modell — sie ist technisch erzwungen auf vier unabhängigen Ebenen. Ein Tenant kann strukturell nicht auf Ressourcen eines anderen Tenants zugreifen, auch wenn beide auf demselben Node-Pool laufen.
Isolationsmodell
Die vier Isolationsebenen
1. Identity Boundary
Jeder Tenant operiert in einem eigenen Identity-Scope. Jede Portal- und API-Anfrage wird gegen zwei unabhängige Bedingungen geprüft: gültige Authentifizierung via OIDC und bestätigte Mitgliedschaft in der korrekten Tenant-Organisation. Es gibt keine Endpunkte, die ohne Tenant-Kontext zugänglich sind.
2. GitOps Boundary
Änderungen an Runtime-Ressourcen sind ausschließlich über Git-Commits möglich. Unser Provisioning-System verwaltet alle Cluster- und Tenant-Konfigurationen deklarativ aus versioniertem Code — direkter Cluster-Zugriff für Tenant-Nutzer ist nicht möglich.
3. Runtime Boundary
Jeder Tenant-Namespace verfügt über dedizierte Ressourcengrenzen, die durch Admission-Policies durchgesetzt werden. Netzwerktraffic zwischen Namespaces wird standardmäßig abgewiesen. Der Ressourcenverbrauch ist auf das vertraglich definierte Tier begrenzt. Container-Workloads laufen unter einem Restricted-Security-Profile, das Privilege-Escalation unterbindet.
4. Secrets Boundary
Tenant-Credentials und -Secrets werden in einem isolierten Bereich unserer Secrets-Authority gespeichert. Secrets werden automatisch in den Tenant-Namespace synchronisiert — Cross-Tenant-Zugriffe sind auf Autorisierungsebene strukturell ausgeschlossen.
Shared vs. Dedicated Capacity
| Modell | Isolation | Wann sinnvoll |
|---|---|---|
| Shared Pool | Namespace + Policy (Ebenen 1–4) | Standard für Starter und Growth |
| Dedicated Bare-Metal | Zusätzlich physisch getrennter Node | Compliance-Anforderungen, volle Ressourcengarantie |
Auf Shared Pools laufen Tenants auf denselben Compute-Nodes, aber mit strikten Resource Quotas und Network Policies. Es ist kein Hypervisor-basiertes Modell — die Isolation ist Kubernetes-nativ mit Cilium-Netzwerk.
Offboarding
Ein standardisiertes Offboarding-Runbook liefert:
- Exportierte Kubernetes-Manifeste aller Tenant-Workloads
- Exportierte Konfigurationen und ConfigMaps
- Persistent-Volume-Snapshots (Longhorn)
- Policy-Kontext und RBAC-Dokumentation
Ziel: ein qualifiziertes Team kann den Tenant-Zustand in einer anderen Kubernetes-Umgebung reproduzieren.
Fragen oder bereit loszulegen?
Mit uns sprechen