Steckbares TLS-Vertrauen: vier CA-Modi zur Absicherung von Zaris

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.

Die vier Modi im Überblick

Jeder Modus führt zum selben Ergebnis: Nodes präsentieren Zertifikate, Clients verifizieren sie gegen eine vertrauenswürdige CA, der Datenverkehr ist verschlüsselt. Der Unterschied liegt darin, wer die Zertifikate ausstellt und wo der Vertrauensanker liegt. Von M0 bis M3 übernimmt Zaris weniger der Ausstellung, und Sie behalten mehr Kontrolle — wählen Sie den Punkt, an dem die Vertrauensgrenze dort verläuft, wo Ihr Security-Team sie haben möchte.

Modus	Name	Wer Node-Zertifikate ausstellt	Vertrauensanker
M0	Auto	Zaris	Von Zaris erzeugte CA
M1	BYO-CA	Zaris, unter Ihrer CA	CA Ihrer Organisation
M2	Intermediate	Zaris, als Intermediate	Ihr Offline-Root, über ein Zaris-Intermediate
M3	Pre-issued	Sie (außerhalb des Systems)	Was auch immer die Zertifikate ausgestellt hat

M0 — Auto: TLS ohne Konfiguration für Entwicklung und einfache Deployments

Im Auto-Modus erzeugt Zaris seine eigene CA und stellt Node-Zertifikate automatisch darunter aus. Es ist nichts bereitzustellen — fahren Sie den Cluster hoch, und die Nodes sprechen bereits TLS untereinander und mit Clients.

Wählen Sie ihn, wenn: Sie entwickeln, eine Demo betreiben oder ein einfaches Deployment aufsetzen, bei dem Betreiber und Nutzer dasselbe Team sind — Verschlüsselung an, ohne Zeremonie.

tls:
  enabled: true
  ca:
    mode: auto        # Zaris generates a CA and issues node certs

Der Kompromiss ist dem selbstsignierten Vertrauen inhärent: Clients müssen einer CA vertrauen, die Zaris erfunden hat, was bedeutet, dass Sie sie an die Clients verteilen müssen. Innerhalb eines Teams ist das in Ordnung; es ist das falsche Modell, sobald Zertifikate zu etwas verketten müssen, dem Ihre Clients bereits vertrauen — und genau das löst der nächste Modus.

M1 — BYO-CA: Verkettung zu einer CA, der Ihre Clients bereits vertrauen

Der Bring-your-own-CA-Modus ist das Arbeitspferd für Organisationen, die bereits eine Unternehmens-CA betreiben. Sie übergeben Zaris Ihre CA, und Zaris stellt Node-Zertifikate darunter aus, sodass das Zertifikat jedes Nodes bis zu einem Root verkettet ist, dem Ihre Clients bereits vertrauen — keine neue CA zu verteilen, keine Eingriffe in die Trust-Stores einzelner Clients.

Wählen Sie ihn, wenn: Sie eine bestehende Unternehmens-CA haben und Zaris-Zertifikate darunter haben möchten. Dies ist die häufigste Wahl in der Produktion.

tls:
  enabled: true
  ca:
    mode: byo               # you provide the CA; Zaris issues node certs under it
    caCert: file:/etc/zaris/pki/org-ca.crt
    caKey:  file:/etc/zaris/pki/org-ca.key

Sie geben Zaris hier einen Ausstellungsschlüssel, behandeln Sie diese Dateien also wie die Geheimnisse, die sie sind — binden Sie sie aus Ihrem Secret-Store ein, nicht aus einem Konfigurations-Repository.

M2 — Intermediate: delegierte Ausstellung mit Offline-Root

Der Intermediate-Modus ist für Organisationen gedacht, die ihre Root-CA offline halten und die Ausstellung an Intermediates delegieren. Zaris arbeitet als Intermediate-CA unter Ihrem Root und präsentiert die vollständige Kette — Node-Zertifikat, dann das Zaris-Intermediate, bis zu Ihrem Root —, sodass ein verifizierender Client den Pfad zu einem Root aufbauen kann, dem er vertraut, obwohl dieser Root dem Cluster nie nahekommt.

Wählen Sie ihn, wenn: Ihre Sicherheitsvorgaben verlangen, dass der Root offline bleibt (oft in einem HSM) und die Ausstellung an eng gefasste Intermediates delegiert wird. Zaris wird eines davon, mit einem Ausstellungsbereich, den Sie kontrollieren, während der Root weggesperrt bleibt.

# Your offline root signs a Zaris intermediate (done once, off the cluster)
openssl x509 -req -in zaris-intermediate.csr \
  -CA root-ca.crt -CAkey root-ca.key -CAcreateserial \
  -extensions v3_intermediate -days 1825 \
  -out zaris-intermediate.crt

# The node must present the FULL chain: node -> intermediate -> root
cat zaris-node.crt zaris-intermediate.crt > zaris-node-fullchain.crt

tls:
  enabled: true
  ca:
    mode: intermediate
    intermediateCert: file:/etc/zaris/pki/zaris-intermediate.crt
    intermediateKey:  file:/etc/zaris/pki/zaris-intermediate.key
    # so clients can build the full path to your offline root
    chain: file:/etc/zaris/pki/zaris-intermediate-fullchain.crt

Die Präsentation der vollständigen Kette entscheidet bei diesem Modus über Gelingen oder Scheitern: Präsentiert ein Node nur sein Leaf-Zertifikat, können Clients, die das Intermediate nicht bereits besitzen, den Pfad zum Root nicht aufbauen, und die Verifizierung schlägt fehl.

M3 — Pre-issued: Sie stellen die Zertifikate aus, Zaris nutzt sie nur

Der Pre-issued-Modus bietet maximale Kontrolle. Sie stellen die Node-Zertifikate selbst bereit, vollständig außerhalb des Systems, und Zaris führt gar keine Ausstellung durch — es lädt und präsentiert die Zertifikate, die Sie ihm geben. Es hält nie einen Ausstellungsschlüssel, weil es nie etwas ausstellt.

Wählen Sie ihn, wenn: Sie sich in einer strikten oder regulierten Umgebung befinden, in der Zertifikate von einem dedizierten System ausgestellt werden — ein PKI-Team des Unternehmens, eine HSM-gestützte Pipeline, cert-manager mit einem kontrollierten Issuer — und keine Anwendung ihre eigenen ausstellen darf. Zaris passt, indem es sich vollständig aus der Ausstellung zurückzieht.

tls:
  enabled: true
  ca:
    mode: provided          # certs minted elsewhere; Zaris only presents them
    nodeCert: file:/etc/zaris/pki/node-fullchain.crt
    nodeKey:  file:/etc/zaris/pki/node.key
    trustBundle: file:/etc/zaris/pki/trust-bundle.crt

Da nichts für Sie ausgestellt wird, verlagert sich die Last vollständig auf Ihren Bereitstellungsprozess: Die Zertifikate müssen bereits die richtigen SANs für jeden Namen tragen, den ein Node bekanntgibt, und die Rotation liegt bei Ihnen.

Ein ehrliches Wort zur Reife

Alle vier Modi sind eine gleichwertige Konfigurationsoption, kein Fork des Builds. Zwei davon sind Wege für Power-User: M2 (Intermediate) steht und fällt mit der korrekten Präsentation der vollständigen Kette (ein Node nur mit Leaf-Zertifikat scheitert bei Clients ohne das Intermediate an der Verifizierung), und M3 (Pre-issued) legt SANs, Schlüsselverwaltung und Rotation vollständig in die Hände Ihres Bereitstellungsprozesses, weil Zaris nichts ausstellt. M0 und M1 sind die reibungslosen Einstiege; greifen Sie zu M2/M3, wenn Ihre PKI es verlangt.

Der Sinn von vier Modi

Der Wert liegt nicht in der Anzahl, sondern darin, dass Sie TLS aktivieren können, ohne gegen Ihre PKI anzukämpfen. Derselbe Store, vier Vertrauensgrenzen: Verschlüsselung gratis in der Entwicklung, Verkettung zu Ihrer Unternehmens-CA in der Produktion, Delegation unter einem Offline-Root oder extern ausgestellte Zertifikate, die Sie übergeben. Sicherheit, die zur Umgebung passt, bleibt eingeschaltet; Sicherheit, die gegen sie arbeitet, wird abgeschaltet.

Wie es weitergeht

Wie ein abgesicherter Cluster von Anfang bis Ende aufgesetzt wird — TLS an, Multi-SAN-Zertifikate, externer Zugriff und ein Client, der sich darüber verbindet —, lesen Sie in Zaris mit Helm auf Kubernetes bereitstellen. Die vollständige Konfigurationsreferenz zu jedem CA-Modus finden Sie im Leitfaden zu den CA-Trust-Modi.