Mandantenmodell und Isolation
Wie gh0stcloud Tenant Identity, Namespace, Policy und Secret-Grenzen klar hält.
gh0stcloud-Tenancy basiert auf Organization Context, Namespace-Grenzen, Policy Checks und gescopten Secret Workflows.
Das öffentliche Versprechen ist kein unbeschränkter Infrastrukturzugriff. Das Produkt ist so gestaltet, dass Tenant-Aktionen über kontrollierte Portal-, API- und GitOps-Pfade laufen.
Isolationsebenen
| Ebene | Grenze |
|---|---|
| Identity | Nutzerzugriff ist an Organization- und Tenant-Kontext gebunden. |
| Portal/API | Aktionen werden gegen Berechtigungen, Tenant State, Policy und Limits geprüft. |
| Namespace | Runtime-Ressourcen werden per Namespace gruppiert und attributiert. |
| Network und Exposure | Connectivity wird durch Plattform-Policy und Tenant Intent gesteuert. |
| Secrets | Secret-Werte bleiben aus Git heraus und laufen über den Tenant Secret Workflow. |
| Capacity | Shared oder Dedicated Capacity hängt von Tenant-Konfiguration und Vertrag ab. |
Shared und Dedicated Capacity
Shared Capacity bedeutet, dass Tenants gemeinsame Plattformkapazität nutzen können, während Identity, Namespace, Policy und Network Controls den Scope begrenzen.
Dedicated Capacity bedeutet, dass Kapazität für einen bestimmten Tenant- oder Kundenscope reserviert ist, sofern vertraglich vereinbart.
Die kommerzielle und technische Bedeutung von Dedicated Capacity sollte im Tenant Agreement bestätigt werden, weil Anforderungen variieren.
Offboarding
Offboarding-Scope hängt davon ab, was der Tenant besitzt und was gh0stservice managed. GitOps-Inhalte, Anwendungskonfiguration, persistente Daten, Credentials und Managed Services brauchen jeweils eigene Übergabepfade.
Gehen Sie nicht davon aus, dass jede Anwendung allein aus öffentlichen Docs anderswo reproduzierbar ist. Klären Sie den Tenant-spezifischen Exit Scope vor Produktions-Onboarding.
Fragen oder bereit loszulegen?
Mit uns sprechen