Sichere mTLS-Authentifizierung zwischen Microservices: Schritt für Schritt
Heute Morgen hab ich wieder diesen ganzen Kram mit Zertifikaten und Handshakes gehabt. Irgendwie versteht man die Kryptographie erst, wenn man sie zum ersten Mal selbst zerschlagen muss. Aber hey, zumindest läuft jetzt alles und ich hab was gelernt.
Fragen & Antworten
- Was ist mTLS genau?
Eine Erweiterung von TLS, bei der sowohl Client als auch Server Zertifikate vorweisen müssen. Keine Zertifikate, kein Zugriff. Einfach, oder? - Warum braucht man mTLS für Microservices?
Services müssen vertrauen können, dass sie sicher miteinander kommunizieren. Ohne mTLS ist es wie ein Geheimnis in ein WhatsApp-Group, das eh jeder lesen kann. - Wie generiert man Zertifikate?
Mit OpenSSL oder HashiCorp Vault. Ich mag Vault, weil es mir sagt: 'Du bist kein Security-Guru, aber das reicht für heute.' - Was passiert, wenn ein Zertifikat abläuft?
Dann ist dein Service offline. Genau das passiert, wenn man nicht automatisierte Renewal-Skripte schreibt. War das würdig? - Kann man mTLS mit Docker nutzen?
Ja, aber nur, wenn du die Zertifikate auch im Container hast. Ein Freund von mir hat das einmal vergessen und sich dafür ein Image mit 2GB angeklickt. Warum nicht einfach nur die .pem-Dateien?
Hauptinhalt
mTLS ist wie ein digitaler Passierschein für Services. Ohne Zertifikate kann keiner durch die Tür. Aber die Einrichtung? Da wird schnell deutlich, dass du nicht der erste bist, der sich fragt, ob das wirklich notwendig ist. Spoiler: Es ist.
Zuerst brauchst du eine Certificate Authority. Das ist wie die Bauministerium deines Internets. Alles, was nicht vorher von dort stammt, wird ignoriert. Ich hab das mit OpenSSL gemacht, weil ich keine Lust hatte, Vault zu konfigurieren. Fehler. Vault ist einfacher, wenn man es einmal versteht.
Dann kommen die Server- und Client-Zertifikate. Jeder Service braucht einen eigenen. Keine Wildcards, keine Abkürzungen. Jeder Zertifikatstyp hat seine Rolle, und wenn du diese verwechselst, dann ist dein Handshake ein Misserfolg. Ehrlich gesagt hab ich das dreimal falsch gemacht, bis es funktioniert hat.
Die Konfiguration der Services ist das eigentliche Drama. Nginx, Envoy oder Istio können das, aber die Dokumentation? Da ist man immer zu drei Schritten von einem Stack Overflow-Fehler entfernt. Ich hab irgendwann aufgehört, die Logs zu leschten, weil die Fehler wieder nur Zertifikate betrafen.
Jedenfalls musst du die Zertifikate irgendwo hinmounten. In Docker-Containern? Dann brauchst du ein Volume. In Kubernetes? Dann ein Secret. Und wenn du das vergisst, dann wartet der Service einfach. Wie ein Hund, der auf einen Befehl wartet, den du vergessen hast abzusetzen.
Übrigens: Testen mit curl ist tricky. Ohne Client-Zertifikat bekommst du nur 'Handshake failure'. Das ist, als würdest du jemandem sagen, dass du nicht zur Party eingeladen bist. Aber mit -cert und -key klappt es plötzlich. War das ein Geheimnis?
Noch mehr Fragen
- Wie oft muss man Zertifikate erneuern?
Je nach Konfiguration. Ein Jahr ist Standard, aber manche setzen auf 90 Tage. Ich hab gemeint, wer braucht schon so oft Ärger mit automatisierten Scripts? - Was kostet mTLS?
Nichts, außer Zeit. Und Nerven. Und manchmal ein bisschen Glück, wenn die CA nicht selbst gehostet wird. - Ist mTLS sicherer als API-Keys?
Absolut. API-Keys sind wie Post-it-Zettel an der Wand. mTLS ist wie ein Büro mit Chipkarte und Bildschirmfoto an der Tür.
Ein Kollege von mir hat mal einen Service mit mTLS geschützt und vergessen, die Renewal-Skripte zu testen. Als das Zertifikat abläuft, war der Service offline. Ein Freund von mir sagte dazu: 'Das ist der Tag, an dem du erfährst, wie wichtig Automatisierung ist.' Ich war nicht dabei, aber ich hab den Horror angeblickt.
Ein anderer hat mTLS aus Versehen auf eine interne API angewendet. Die Performance war unterirdisch, weil er nicht bedacht hat, dass jedes Zertifikat auch Bandbreite frisst. Sein Satz: 'Ich dachte, mehr Sicherheit = besser. Hat sich nicht bewährt.'
Dann war da noch der, der mTLS mit selbstsignierten Zertifikaten für den Produktivbetrieb missbrauchte. Er hat es geschafft, aber die Zertifikate wurden nie aktualisiert. Jedes Mal, wenn er einen neuen Service deployed, fragte er sich, ob das wirklich sicher ist. Keine Ahnung, aber es lief.
mTLS ist nicht das Einzige, um Services zu schützen. OAuth2, JWT oder einfache API-Keys sind Alternativen. Aber wenn es um tiefes Vertrauen geht, dann ist mTLS der Weg. OAuth2 ist wie ein Einladungsschreiben, mTLS ist wie ein Notar.
Vault vs. OpenSSL: Vault ist moderner, OpenSSL ist robuster. Ein Freund von mir setzt lieber auf OpenSSL, weil er Vault nicht verträgt. Ich verstehe das. Vault ist wie ein Schreibtisch, der plötzlich mehr Tasten hat als nötig.
LetsEncrypt vs. eigene CA: LetsEncrypt ist kostenlos, eigene CA gibt dir Kontrolle. Einmal hab ich LetsEncrypt für interne Services genutzt. Das war wie ein Notfallplan, der nicht funktioniert. Weil die Services nicht von außen erreichbar sind.
mTLS ist kein Allheilmittel. Wenn dein Netzwerk unsicher ist, hilft es nichts. Ein Freund von mir hat das geregelt und sagt heute zu jedem Sicherheitsthema: 'Mach erstmal das Netzwerk richtig.'
Ein weiterer Einsicht: mTLS verlangt, dass alle Services wissen, wer die CA ist. Das heißt, wenn die CA kompromittiert wird, dann ist alles zerstört. Ein Kollege hat das einmal erlebt und sagt: 'Nie wieder eine CA hosten, die ich nicht kontrollieren kann.'
mTLS ist nicht schwer, aber es ist komplex. Wenn du es das erste Mal machst, dann mach es langsam. Ein Freund von mir hat es in einer Nacht geschafft. Ohne Schlaf. Ohne Erfolg. Mit viel Kaffee.
