Jeder Nutzer hat eine Rolle und einen Anwendungsbereich, jede Anmeldung braucht einen zweiten Faktor, jede Änderung steht im Audit-Log. Zugangsdaten werden verschlüsselt gespeichert und nie wieder ausgegeben.
Sicherheit in Clusterward beginnt bei der Anmeldung: benannte Nutzer mit Passwort und Pflicht-2FA per TOTP, Kontosperre und Ratenbegrenzung. Darauf sitzt RBAC: Jede Rolle vergibt pro Bereich eine Stufe von „kein Zugriff“ bis „verwalten“, dazu kommt ein Anwendungsbereich, der einen Nutzer auf seine Anwendungen und alles darunter begrenzt. Jede Route ist standardmäßig gesperrt, bis sie einer Berechtigung zugeordnet ist. Jede Änderung schreibt einen Audit-Eintrag mit Person, Aktion und Objekt, nie mit Geheimnissen. Und jeder Kunde erhält einen eigenen Workspace mit eigener Datenbank, eigenem Schlüssel und eigenem Backup-Bucket.
Passwort plus TOTP-Code; nach zu vielen Versuchen sperrt das Konto.
Die IP-Allowlist des Workspaces greift vor der Anmeldung, mit echter Client-Adresse.
Die Route verlangt eine Stufe in einem Bereich; ohne Zuordnung ist sie gesperrt.
Ein Nutzer sieht nur seine Anwendungen und alles, was darunter hängt.
Die Änderung landet im Audit-Log, die Nachricht ohne Geheimnis im Kanal.
Keine Checkliste für später, sondern Voreinstellungen, die Sie nicht abschalten müssen.
Zwei Faktoren für alle, Einladungen statt geteilter Passwörter.
Jeder Nutzer richtet TOTP ein, bevor er arbeitet. Das Geheimnis liegt verschlüsselt, Anmeldeversuche sind pro Adresse begrenzt, Konten sperren sich nach Fehlversuchen.
Neue Nutzer bekommen einen Link, mit dem sie ihr Passwort selbst setzen. Auch der erste Administrator eines Workspaces startet mit einer Einladung.
Ein Link setzt das Passwort neu, zehn einmalige Wiederherstellungscodes ersetzen den Authenticator. Die 2FA bleibt immer Pflicht.
Eine Adresse mit zu vielen Fehlversuchen wird eine Stunde gesperrt, bei Wiederholung einen Tag. Eine Anmeldung von einer neuen Adresse meldet sich per E-Mail beim Kontoinhaber.
Eine Sitzung endet nach zwei Stunden ohne Aktivität und spätestens nach zwölf. Neue Passwörter brauchen mindestens 12 Zeichen, neue Wiederherstellungscodes gibt es nur mit dem aktuellen Code aus der Authenticator-App, und das Cockpit nimmt Änderungen nur von der eigenen Adresse an.
Jeder darf nur, was er braucht, und jede Aktion hat einen Namen.
Eine Rolle ist eine Matrix aus Bereichen und Stufen. Der feste Administrator hat alles, jede andere Rolle nur, was sie braucht; Rollen, Bereiche und API-Tokens vergibt jeder nur im Rahmen der eigenen Rechte. Ein Bereich beschränkt Nutzer auf ihre Anwendungen, Datenbanken und Buckets – samt Kunden-Läufen, Backups und Bucket-Schlüsseln.
Tokens für CI-Pipelines tragen eine Rolle, einen Anwendungsbereich und ein Ablaufdatum. Sie können nie Tokens, Nutzer oder Rollen verwalten, nie Administrator sein, und jede Aktion steht unter ihrem Namen im Audit-Log.
Jede Mutation, jeder Download eines Dumps, jede Rotation eines Schlüssels: Person, Zeitpunkt, Aktion, Objekt. Werte von Geheimnissen stehen nie darin, nur ihre Art. Im Cockpit unter System → Audit-Log durchsuchbar und filterbar; eine Auditor-Rolle liest mit, ohne Nutzer zu verwalten.
Die SQL-Konsole hat eine eigene Berechtigung, die aus keinem Datenbankrecht folgt. Sie fragt mit einem eigenen Lese-Login in einer Nur-Lese-Transaktion ab, und jede Abfrage steht mit Text, Zeilenzahl und Dauer im Audit-Log – nie mit Werten. API-Tokens können sie nicht nutzen.
Was einmal gespeichert ist, kommt nicht mehr heraus.
Scaleway-Schlüssel, Kubeconfigs, Git-Tokens und Datenbank-Admins werden vor dem Speichern geprüft, verschlüsselt abgelegt und nie zurückgegeben. Lesbar sind nur Anwendungsvariablen und Verbindungsdaten, die Sie kopieren müssen. Eintragen und Rotieren verlangt die Stufe „verwalten“ – ebenso jede Änderung daran, wohin ein gespeicherter Schlüssel geschickt wird.
Secrets sind ab dem Speichern nur noch überschreibbar, auch für Administratoren. Auf Wunsch liegen sie im Scaleway Secret Manager Ihres Projekts, mit Versionen und Rotation.
Wer den Workspace und die Kubernetes-API erreicht – und was im Cluster darf.
Ein Workspace begrenzt sich auf Adressbereiche; die Prüfung kennt Cloudflare-Adressen und lehnt gefälschte Header ab. Ein Aussperren der eigenen Adresse wird verhindert.
Die Karte am Cluster zeigt, welche Adressen die Kubernetes-API erreichen dürfen. „Meine IP hinzufügen“ ersetzt nach einem IP-Wechsel den Weg in die Scaleway-Konsole.
Mit einem Klick bekommt eine Umgebung Netzwerk-Richtlinien: Nur die Ingress-Controller und die eigenen Pods kommen hinein, der Metadaten-Dienst der Nodes bleibt unerreichbar. System → Sicherheit zeigt, welche Umgebungen noch offen sind. Kommt ein Ingress-Controller hinzu oder fällt einer weg, passen sich die Richtlinien selbst an; wer die Stufe „verwalten“ hat, hebt die Isolation wieder auf.
Die Cluster-Identität liest den Cluster ohne Secrets und schreibt nur in den Namespaces, die sie für Ihre Umgebungen angelegt hat; Richtlinien im Cluster halten das fest. Admin-Zugriff für Add-ons gilt eine Stunde, Builds pushen mit einem Schlüssel nur für die Registry. Ab Kubernetes 1.30.
Pods mit Seccomp, ohne Privilegien-Eskalation und ohne Capabilities. Die Namespaces Ihrer Umgebungen laufen mit Pod Security „baseline“; wo ein laufender Pod noch dagegen verstößt, meldet das Cockpit es, statt ihn zu stoppen.
Scaleway, Cloudflare und Kubernetes werden über ihre HTTP-APIs angesprochen; die Abhängigkeiten bleiben klein.
AES-256-GCM pro Workspace mit einem eigenen, vom Plattformschlüssel umhüllten Datenschlüssel.
Eigene Datenbank und eigener Backup-Bucket pro Workspace, keine gemeinsamen Tabellen.
Betrieb bei Scaleway in der EU durch die BitKollegen GmbH.
Eine Rolle vergibt pro Bereich genau eine Stufe. Dazu kommt „alle Anwendungen“ oder eine Liste eigener Anwendungen.
| Stufe | Erlaubt | Beispiel |
|---|---|---|
| kein Zugriff | Nichts in diesem Bereich | Entwickler ohne Cluster-Einblick |
| ansehen | Lesen | Support liest Deployments und Logs |
| bedienen | Alltag: deployen, neu starten, anlegen | Entwickler rollt seine Anwendung aus |
| verwalten | Löschen, Zugangsdaten eintragen, Upgrades, Helm-Charts schreiben | Team-Lead verwaltet Cluster |
| Administrator | Alles, fest, nicht editierbar | Betreiber des Workspaces |
Die eingeschränkte Operator-Identität entsteht beim Cluster-Provisioning; gehärtete Pods und NetworkPolicies gehören zu Deployments.
Wo Ihre Daten liegen und warum der Betrieb in der EU eine Entscheidung ist, lesen Sie unter Digitale Souveränität. Die Antworten auf DSGVO-Fragen und der Auftragsverarbeitungsvertrag stehen im Kontakt bereit.
Kapsule-Cluster sicher ab Werk, mit Private Network und Gateway.
Zu Cluster-ProvisioningGit, Container-Image oder Helm-Chart – mit Health-Check ausgerollt.
Zu DeploymentsWebhook, Slack, Teams oder E-Mail – einmal pro Ereignis.
Zu BenachrichtigungenIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenIn der Demo zeigen wir Rollen, Audit-Log und Isolation an einem echten Workspace und beantworten Ihre Fragen zu DSGVO und AVV.
