Sicherheit und Compliance
Identity, Secrets, Admission-Policies und Datenresidenz in Deutschland.
gh0stcloud ist Germany-first konzipiert: alle Infrastruktur läuft in deutschen Hetzner-Rechenzentren, alle Daten bleiben in der EU, und sämtliche Security Controls sind kodiert — nicht dokumentiert und manuell angewendet.
Sicherheitsmodell auf einen Blick
| Domäne | Control | Implementierung |
|---|---|---|
| Identity | OIDC, PKCE, OAuth2 | Keycloak Organization Boundaries |
| Authorization | Capability Roles + Tenant Scope | Keycloak Groups + gh0stplane RBAC |
| Secrets | Zentralisierte Secrets Authority | OpenBao + External Secrets Operator |
| Runtime Policy | Admission Control + NetworkPolicy | Kyverno Admission Policies |
| GitOps Integrity | Nur Flux CD darf reconcilen | Cluster RBAC: kein direkter Apply-Zugriff |
| Auditability | Unveränderliche Change History | Git Commit History + gh0stplane Audit Log |
Authentifizierung und Autorisierung
Alle Zugriffe auf das Portal und die API durchlaufen einen zweistufigen Check:
Schritt 1 — Authentifizierung: Ein OIDC-Token von Keycloak wird über den PKCE-Flow ausgestellt (kein Implicit Flow) und gegen die Keycloak JWKS validiert.
Schritt 2 — Autorisierung: Jede Anfrage wird gegen zwei Bedingungen geprüft — die erforderliche Capability (z. B. Lesen von Namespace-Daten) und die Zugehörigkeit zur korrekten Tenant-Organization. Es gibt keine globalen Rollen ohne Tenant-Kontext.
Secrets und Credential-Lifecycle
- OpenBao ist die einzige Secrets Authority. Secrets werden in tenant-scoped Pfaden verwaltet.
- ESO synchronisiert Secrets tenant-scoped in Kubernetes-Namespaces — keine manuellen Workflows für Secret-Erstellung
- Rotation: Credentials werden über policy-gesteuerte Rotation in OpenBao verwaltet
- Kein Secret-Plaintext in Repositories — nur Referenzen auf Secret-Pfade in OpenBao
Kyverno Admission Control
Kyverno erzwingt auf jedem Runtime Cluster mehrere Admission Policies:
- Namespace Labels — Pflicht-Labels für Telemetry und Billing
- Pod Security — Restricted PSS für Tenant-Pods (kein
privileged, keinhostNetwork) - NetworkPolicy Baseline — Default-Deny inter-namespace, explizites Allow für intra-namespace
- Resource Quotas — Tier-abhängige CPU/Memory-Limits
- Image Registry — Allowlist für erlaubte Container-Registries
- Service Account — Kein automounted Token für ungenutzte ServiceAccounts
- Ingress Scope — Tenant-Ingresses dürfen nur eigene Hostnames verwenden
- Secret Access — ESO-Secrets nur aus dem tenant-eigenen Secrets-Bereich
Datenresidenz und DSGVO
- Infrastruktur ausschließlich in deutschen Hetzner-Rechenzentren (Nürnberg, Falkenstein)
- Keine Datenübertragung in Drittländer außerhalb der EU
- Alle Logs, Metriken und Traces verbleiben in der Management Plane in Deutschland
- Vertragsgrundlage nach DSGVO Art. 28 (Auftragsverarbeitung) auf Anfrage
Shared Responsibility
| Bereich | gh0stservice | Kunde |
|---|---|---|
| Platform Hardening & Patching | ✓ | — |
| Cluster- und Control-Plane-Lifecycle | ✓ | — |
| Kyverno-Policies (Platform-Ebene) | ✓ | — |
| Application Code und Dependencies | — | ✓ |
| Data Governance (Application-Level) | Guidance | ✓ |
| Tenant-eigene Secrets-Rotation | Support | ✓ |
Penetration Testing und Compliance Evidence
- Infrastruktur-seitige Penetration Tests werden regelmäßig durchgeführt
- Compliance Evidence Packages (Konfigurationsnachweise, Audit Logs, Policy-Exports) können für Enterprise-Verträge und Audits bereitgestellt werden
- BSI IT-Grundschutz-orientierte Controls für kritische Infrastruktur-Komponenten
Fragen oder bereit loszulegen?
Mit uns sprechen