Sicherheit ist kein Feature. Sie ist die Architektur.
Konductly verwaltet die Zugangsdaten zu Ihrer kritischen Infrastruktur. Deshalb ist jede Ebene — von der Verschlüsselung über die Authentifizierung bis zum Hosting — darauf ausgelegt, dass Ihre Daten unter Ihrer Kontrolle bleiben.
Ihre Zugangsdaten verlassen den Klartext nie
Kubeconfigs, ServiceAccount- und Bearer-Token sind das Kronjuwel Ihrer Infrastruktur. Konductly speichert sie ausschließlich verschlüsselt und entschlüsselt sie erst im Arbeitsspeicher — für die Dauer einer einzelnen Anfrage.
- AES-256-GCM für alle Cluster-Credentials at rest — authentifizierte Verschlüsselung
- Schlüssel aus HashiCorp Vault, nie im Repository oder Container-Image
- Entschlüsselung nur zur Laufzeit, kein Klartext in Logs oder Cache
Kurzlebige Tokens statt Dauer-Zugang
Ein gestohlenes Token soll wertlos sein, bevor es jemand nutzen kann. Konductly setzt auf kurzlebige Access-Tokens und rotierende Refresh-Tokens — vollständig im eigenen Backend, ohne externen Auth-Dienst.
- JWT Access-Token mit 15 Minuten Gültigkeit (HS256)
- Refresh-Token: 7 Tage in Redis, Rotation bei jedem Refresh
- Passwörter mit bcrypt gehasht (Cost ≥ 10), Secret nur aus der Umgebung
Jeder Cluster-Zugriff wird neu autorisiert
Konductly vertraut keiner Verbindung implizit. Für jede Anfrage wird ein frischer Kubernetes-Client aus den entschlüsselten Zugangsdaten gebaut — kein gecachter Klartext, kein dauerhaft offener Tunnel in Ihre Cluster.
- Dynamischer Client-Aufbau pro Request, kein persistenter Zugang
- Unterstützt Kubeconfig, ServiceAccount- und Bearer-Token
- Zugriff streng begrenzt auf autorisierte Cluster und Namespaces
Klare Rollen — Admin und Viewer
Nicht jede Person im Team braucht die Macht, Workloads zu löschen. Konductly trennt lesenden Einblick von steuerndem Eingriff über ein rollenbasiertes Berechtigungsmodell auf API-Ebene.
- Admin: Cluster anbinden, Pods/Deployments/Container steuern, Kosten einsehen
- Viewer: read-only — Monitoring und Kosten, keine mutierenden Aktionen
- Durchsetzung serverseitig per GraphQL-Directive, nicht nur in der UI
Die API bleibt unter Last beherrschbar
Eine offene GraphQL-API ist ein beliebtes Ziel für Resource-Exhaustion. Konductly begrenzt Tiefe, Komplexität und Frequenz jeder Abfrage — pro Identität, nicht nur global.
- Query-Depth-Limit gegen tief verschachtelte Abfragen
- Query-Complexity-Limit gegen teure Einzelabfragen
- Rate-Limiting pro Nutzer-ID bzw. IP (Redis-basiert)
Log-Streams erst nach Authentifizierung
Live-Logs und Echtzeit-Metriken laufen über WebSockets. Die Authentifizierung wird geprüft, bevor die Verbindung überhaupt aufgebaut wird — ein anonymer Lauschangriff scheitert vor dem Upgrade.
- Auth-Check im connection_init, vor dem Protokoll-Upgrade
- Zugriff nur auf autorisierte Cluster, Namespaces und Pods
- Saubere Beendigung der Streams bei Token-Ablauf oder Abbruch
On-Premise: Ihre Daten bleiben bei Ihnen
Konductly läuft auf eigener Infrastruktur (on-prem / Hetzner) in der EU. Keine Datenreise über den Atlantik, kein CLOUD-Act-Risiko über die Hintertür — Datenkontrolle ist eingebaut, nicht zugekauft.
- EU-Hosting, kein US-Anbieter in der Verarbeitungskette
- DSGVO-konform by design, keine Übermittlung in Drittländer
- Audit-Logs für mutierende Aktionen, automatische Löschung nach 90 Tagen
Überzeugen Sie sich selbst.
Verbinden Sie Ihren ersten Cluster und sehen Sie, wie Konductly Ihre Zugangsdaten schützt — oder sprechen Sie mit uns über Ihre Anforderungen.
Mehr Details in der DSGVO-Übersicht und der Dokumentation.