3 Posts getaggt mit "Sicherheit"

Die meisten Wege, einem verteilten Datenspeicher eine Authentifizierung vorzuschalten, enden damit, ein zweites verteiltes System zu seinem Betrieb hinzuzufügen: einen Auth-Dienst, den man aufrufen muss, eine Session-Datenbank, die repliziert werden muss, einen Token-Introspection-Endpunkt, den jeder Node auf dem Hot Path erreichen muss. Sie haben den Store gesichert und sich eine neue Verfügbarkeitsabhängigkeit und eine neue Latenzquelle eingekauft.

Zaris geht einen anderen Weg, und zwar einen bewusst langweiligen: ein Signaturschlüssel pro Cluster und Tokens, die jeder Node selbst verifizieren kann. Ein Token ist ein JWT, signiert mit dem privaten Schlüssel des Clusters; jeder Manager und jeder Node hält die öffentliche Hälfte und prüft die Signatur offline — kein Aufruf an einen Auth-Server, kein Quorum, kein Datenbank-Lookup. Security ist standardmäßig aus, und ein Cluster mit ausgeschalteter Security verhält sich exakt wie ein ungesicherter. Dieser Beitrag handelt davon, was sich einschaltet, wenn Sie sie aktivieren: die Form des Tokens, das Rollen-und-Scope-Modell, die beiden Ebenen, auf denen die Durchsetzung tatsächlich stattfindet, und — weil das Gegenteil vorzutäuschen der Weg zu einem falschen Sicherheitsgefühl ist — die betrieblichen Grenzen, die man leicht falsch macht.

Der sicherste Weg, TLS zu umgehen, ist, allen ein einziges Vertrauensmodell aufzuzwingen. Ein Entwickler, der einen Store auf dem Laptop betreibt, möchte keine CA aufsetzen. Eine Bank mit einem Offline-Root in einem HSM möchte nicht, dass Ihr Tool überhaupt Zertifikate ausstellt. Liefern Sie einen Store aus, der nur eines davon kennt, schaltet die Hälfte Ihrer Nutzer die Sicherheit ab, um ihre Arbeit zu erledigen.

Deshalb entscheidet Zaris nicht für Sie. Das TLS-Vertrauen ist über vier Certificate-Authority-Modi hinweg steckbar, von selbstsigniert ohne Konfiguration bis hin zu Zertifikaten, die Sie vollständig außerhalb des Systems bereitstellen. Sie wählen den Modus, der zur PKI passt, die Sie ohnehin betreiben, und Zaris fügt sich ein, statt von Ihnen einen Umbau zu verlangen. TLS ist keine Einheitslösung, und genau deshalb wird Sicherheit so oft aufgeschoben, wenn man es so behandelt.

Einen verteilten Store auf Kubernetes zu bringen, ist einfach. Ihn dort mit aktiviertem TLS, von außerhalb des Clusters erreichbar und mit einem Client, der sich tatsächlich verbindet bereitzustellen, ist der Punkt, an dem die meisten Anleitungen stillschweigend aufhören. Zaris liefert ein Helm-Chart, und wir haben den gesamten Weg — einschließlich der abgesicherten, extern erreichbaren Konfiguration — End-to-End auf einem lokalen Cluster validiert.

Dieser Beitrag ist diese Anleitung. Wir führen sie auf kind (Kubernetes-in-Docker) aus, damit Sie jeden Schritt auf einem Laptop nachvollziehen können, und wählen bewusst den schwierigeren Weg: TLS aktiviert, Zertifikate mit den richtigen Subject Alternative Names, externer Zugriff an und ein Client, der sich über den abgesicherten Endpunkt verbindet. Wir nennen das die Model-B-Konfiguration — extern erreichbar und abgesichert, im Gegensatz zu einem rein internen Cluster.

Eine Korrektheitsregel bringt fast jedes erste Deployment ins Stolpern, und sie hat nichts mit Zertifikaten zu tun: Der Store-Name in Ihrem Connection String muss mit der clusterId des Deployments übereinstimmen. Wir zeigen genau, wo das zuschlägt. Alles andere ist auf einem Produktions-Cluster identisch — kind bietet lediglich einen sauberen Wegwerf-Ort, um es zu beweisen.