Sicherheit von Anfang an eingebaut, nicht nachgerüstet
Authentifizierung, Autorisierung und Verschlüsselung sind Teil des Stores – ein Vertrauensgeflecht über Datenebene und Konsole, pro Store konfigurierbar, ohne zusätzliche Dienste, die Sie betreiben müssen.
Drei Schichten, ein Geflecht
Ein integriertes Vertrauensgeflecht sichert den Node-zu-Node-Verkehr, Client-Verbindungen und die Verwaltungsebene – mit demselben Identitäts- und Autorisierungsmodell im gesamten Cluster.
Authentifizierung
Offline verifizierte Bearer-Tokens – der Node prüft die Signatur gegen einen zwischengespeicherten Cluster-Schlüssel, ohne Roundtrip zu einem Auth-Server auf dem Hot Path.
Autorisierung
RBAC mit Deny-by-Default – Subjekte erhalten Rollen, Rollen gewähren Berechtigungen auf Stores und Admin-Operationen. Nichts ist erlaubt, solange es nicht gewährt wurde.
Verschlüsselung
Mutual TLS zwischen Nodes und TLS mit Server-Authentifizierung für Clients, über vier CA-/Vertrauensmodelle – pro Store aktivierbar.
Tokens, offline verifiziert
Clients legen ein Bearer-Token vor; der Node prüft dessen Signatur gegen den zwischengespeicherten öffentlichen Schlüssel des Clusters – ohne Aufruf eines Auth-Servers im Request-Pfad. Halten Sie das Token mit env:- oder file:-Referenzen aus dem Connection String heraus.
- Keine Abhängigkeit von einem Auth-Server auf dem Hot Path
- Vom Manager ausgestellte Tokens; begrenzt im Geltungsbereich und befristet
- Sichere Indirektion – Secrets stehen nie in der URL
zariss://n0:7861/store?token=env:ZARIS_TOKENMutual TLS im gesamten Cluster
Gossip und Replikation zwischen Nodes laufen über Mutual TLS; die Client-Datenebene arbeitet mit Server-Authentifizierung, bei der der Client den Node prüft und sich per Token authentifiziert. Unter Kubernetes kann das Node-Zertifikat ein Multi-SAN-Zertifikat sein, sodass auch externe Clients es validieren.
- Mutual TLS Node ↔ Node; Server-Authentifizierung für Clients
- Automatische Erneuerung der Zertifikate vor Ablauf
- Pro Store aktivierbar – Klartext bleibt der Default für die Entwicklung
Vier CA-/Vertrauensmodelle
Von automatischer Ausstellung ohne PKI bis zum Einbinden von Zertifikaten Ihrer eigenen CA – wählen Sie das Vertrauensmodell, das zu Ihrer Organisation passt.
M0 · Automatisch / Co-located
Der Manager erstellt eine Cluster-CA und stellt Node-Zertifikate automatisch aus. Keine PKI zu betreiben – ideal, um schnell sicher zu starten.
M1 · Eigene CA mitbringen
Stellen Sie Ihre eigene Root-CA bereit; der Cluster stellt daraus Zertifikate aus, sodass Zaris an eine Vertrauensstellung anknüpft, die Sie bereits betreiben.
M2 · Zwischen-CA
Zertifikate werden von einer Zwischen-CA unter Ihrer Unternehmens-Root ausgestellt; Node-Zertifikate legen die vollständige Kette bis zur verankernden Root vor.
M3 · Vorab ausgestellte Zertifikate
Binden Sie extern ausgestellte Zertifikate + CA als Secrets ein (z. B. cert-manager). Zaris lädt und verwendet sie einfach.
Konfigurieren und prüfen an einem Ort
Initialisieren Sie die Cluster-CA, erstellen Sie Enrollment-Tokens, wählen Sie das Vertrauensmodell und sehen Sie den TLS-Status pro Node – alles in der integrierten Ansicht „Security & TLS“.
Sicher durch Konfiguration, nicht durch ein Projekt
Aktivieren Sie Tokens, RBAC und TLS pro Store – ohne einen eigenen Sicherheitsdienst, den Sie bauen, betreiben und aktuell halten müssen.