Verwendung von gegenseitigem TLS zur Sicherung des Kubernetes-Workload-Verkehrs (2023)

Dmitri Dubson

Dieser Leitfaden führt Sie durch die Schritte zum Aufbau einer funktionierenden Implementierung von Kubernetes-Workloads, die intern über gegenseitiges TLS (mTLS) kommunizieren. Die Beispiel-Clientanwendung und -Dienst in diesem Handbuch stellen eine funktionierende Instanz einer solchen Architektur dar und können auf viele andere Open-Source- oder proprietäre Dienste angewendet werden, die die Verkehrsverschlüsselung mit mTLS unterstützen.

Es wurde speziell für Anwendungsentwickler geschrieben, die mithilfe von gegenseitigem TLS eine weitere Sicherheitsebene zu ihrem Kubernetes-Workload-Verkehr hinzufügen möchten, und erfordert praktische Kenntnisse der grundlegenden Kubernetes-Konstrukte und Befehlszeilenoperationenkubectl.

Nach Abschluss dieses Leitfadens sollten Sie über praktische Kenntnisse und eine funktionierende Referenzimplementierung von Workloads verfügen, die über gegenseitiges TLS kommunizieren.

Dieser Leitfaden besteht aus drei Abschnitten:

• Teil I: Workloads erstellenDefiniert einen Redis-Workload und einen Spring Boot-Clientanwendungs-Workload, die auf dem Cluster ohne Datenverkehrsverschlüsselung kommunizieren.
• Teil II: mTLS aktivierenAktualisiert das Design, um gegenseitiges TLS einzubeziehen, und führt einen Zertifikatsmanager in den Cluster ein, um die Erstellung erforderlicher Zertifikate für die Bereitstellung von verschlüsseltem Datenverkehr mithilfe von gegenseitigem TLS zu unterstützen.
• Teil II (Erweiterter Schnitt): CA-Zertifikate mithilfe von Servicebindungen verwaltenBehebt ein potenzielles Problem mit einem JVM-basierten CA-Zertifikat-Truststore, das für Leser nützlich sein könnte. Dieser Abschnitt ist optional.

Teil I: Workloads erstellen

Richten Sie in einer Sandbox einen lokalen, funktionierenden Kubernetes-Cluster ein.

Hinweis: Da dieses Handbuch nur zu Demonstrations- und Evaluierungszwecken dient, wird empfohlen, Workloads aus einer Sandbox zu erstellen.

Es gibt einige Tools, mit denen Sie einen lokalen Kubernetes-Cluster mit einem einzelnen Knoten einrichten können. Die Beispiele in diesem Handbuch verwendenArt.Zwei weitere zu berücksichtigende Tools sind:

• Minikube
• MicroK8s.

Führen Sie Folgendes aus, um eine funktionierende Kubernetes-Umgebung zu überprüfen:

kubectl-Cluster-Info

Um sicherzustellen, dass Sie in einer ordnungsgemäßen Sandbox arbeiten, überprüfen Sie Ihren aktuellen Kontext, indem Sie Folgendes ausführen:

kubectl config aktueller Kontext

Sie sollten einen bekannten Sandbox-Umgebungsnamen sehen. Stellen Sie sicher, dass dies der Kontext ist, in dem Sie arbeiten möchten.

Erstellen Sie eine leere Yaml-Datei mit dem Namenmtls-demo.yaml. Sie werden diese Datei als eines Ihrer Hauptartefakte für dieses Handbuch verwenden.

Erstellen Sie zunächst einen Kubernetes-Namespace für diese Demonstration mit dem Namenmtls-demo:

Hängen Sie diese Definition an das Leerzeichen anmtls-demo.yamlDatei

apiVersion: v1Art: NamensraumMetadaten: Name: mtls-demo

kubectl apply -f mtls-demo.yaml

Erstellen Sie als Nächstes eine grundlegende Redis-Server-Kubernetes-Bereitstellung und einen Kubernetes-Dienst innerhalb des Clusters mit der folgenden Definition:

Hängen Sie diese Definition an anmtls-demo.yamlDatei.

---apiVersion: apps/v1Art: EinsatzMetadaten: Namensraum: mtls-demo Name: Redis-Serverspez: Repliken: 1 Wähler: matchLabels: Name: Redis-Server Vorlage: Metadaten: Etiketten: Name: Redis-Server spez: Behälter: -Name: Redis-Server Bild: bitnami/redis:6.2.6 Häfen: -ContainerPort: 6379 env: -Name: ALLOW_EMPTY_PASSWORD Wert: "Ja"---apiVersion: v1Art: ServiceMetadaten: Name: Redis-Server Namensraum: mtls-demospez: Häfen: -Hafen: 6379 ZielPort: 6379 Wähler: Name: Redis-Server

kubectl apply -f mtls-demo.yaml

Der Redis-Server aktiviert die TLS-Unterstützung standardmäßig nicht. Ein Teil des Ziels besteht darin, diese Unterstützung in zukünftigen Schritten zu ermöglichen. Zunächst möchten Sie, dass ein Redis-Server innerhalb des Clusters läuft und zugänglich ist. Für diese Demonstration ist die Passwortunterstützung in Redis deaktiviert, sodass Sie sich auf die Aktivierung der TLS-Unterstützung konzentrieren können. Informationen zur Verwendung eines ordnungsgemäßen Passwortschutzes finden Sie in den offiziellen Redis-Richtlinien.

Wenn alles erfolgreich abgeglichen wurde, sollte im Cluster ein Redis-Server ausgeführt werden. Führen Sie Folgendes aus, um zu überprüfen, ob Sie mit dem Redis-Server kommunizieren können:

kubectlGeschäftsführerDeployment/redis-server -n mtls-demo – redis-cli ping

Als Antwort sollte „PONG“ angezeigt werden. Dies ist die Antwort von Redis auf eine „Ping“-Nachricht, die als einleitender Wählton fungiert.

Erstellen Sie als Nächstes eine Clientanwendung, um eine Verbindung zur Redis-Instanz herzustellen. Verwenden Sie für diesen Schritt eine Spring Boot-Beispielanwendung mit einer Spring Data Redis-Bibliotheksintegration. Das Docker-Image für die Anwendung wird mithilfe von Spring Boot Gradle-Plugins erstellt.bootBuildImageAufgabe, auf die man sich verlässtCloud Native Buildpacks.

Um den Code für diese Beispielanwendung zu überprüfenGehe hier hin.

Das wiederverwendbare Docker-Image ist veröffentlicht amDocker-Hubmit Namen und Anhängerddubson/spring-boot-redis-mtls-demo:basic.

Erstellen Sie nun eine Clientanwendungsbereitstellung mit dem Docker-Image der Clientanwendung.

Hängen Sie diese Definition an anmtls-demo.yamlDatei.

---apiVersion: apps/v1Art: EinsatzMetadaten: Etiketten: App: Spring-Boot-Redis-Client-App Name: Spring-Boot-Redis-Client-App Namensraum: mtls-demospez: Repliken: 1 Wähler: matchLabels: App: Spring-Boot-Redis-Client-App Vorlage: Metadaten: Etiketten: App: Spring-Boot-Redis-Client-App spez: Behälter: -Bild: ddubson/spring-boot-redis-mtls-demo:basic Name: Spring-Boot-Redis-Client-App env: -Name: SPRING_REDIS_HOST Wert: „Redis-Server“ -Name: SPRING_REDIS_PORT Wert: „6379“ Häfen: -ContainerPort: 8080 Name: App-Port Protokoll: TCP livenessProbe: httpGet: Weg: /Aktuator/Gesundheit Hafen: App-Port BereitschaftProbe: httpGet: Weg: /Aktuator/Gesundheit Hafen: App-Port---apiVersion: v1Art: ServiceMetadaten: Etiketten: App: Spring-Boot-Redis-Client-App Name: Spring-Boot-Redis-Client-App Namensraum: mtls-demospez: Häfen: -Name: Service-Port Hafen: 8080 Protokoll: TCP ZielPort: 8080 Wähler: App: Spring-Boot-Redis-Client-App Typ: ClusterIP

kubectl apply -f mtls-demo.yaml

Die obige Bereitstellungsdefinition einer Spring Boot-Clientanwendung basiert darauf, dass die Redis-Dienstressource im Cluster unter der Hostadresse verfügbar istRedis-Serveram Hafen6379. Die TLS-Unterstützung ist noch nicht aktiviert, daher weist die Definition außer dem Host und dem Port des Redis-Servers keine Konfiguration auf.

Die Anwendung ist mit einer Liveness- und Readiness-Prüfung konfiguriert. Wenn der Abgleich erfolgreich ist, wissen Sie, dass die Verbindung zu Redis erfolgreich hergestellt wurde.

Zur zusätzlichen Überprüfung verfügt die Clientanwendung über einen API-Endpunkt, der abgefragt werden kann. Dieser interagiert insbesondere mit Redis:

kubectl port-forward svc/spring-boot-redis-client-app 8080:8080 -n mtls-demo# In einem anderen Terminalfenster/Tabcurl -XGET http://localhost:8080/# Als Antwort sollten Sie eine zufällige UUID-Zeichenfolge erhalten.

Sie können nun die Portweiterleitung stoppen und mit den nächsten Schritten fortfahren.

Die Clientanwendung kann über eine unverschlüsselte Verbindung mit Redis im Cluster interagieren. Jetzt können Sie sich darauf konzentrieren, den Datenverkehr zwischen Redis und der Clientanwendung mithilfe von gegenseitigem TLS zu sichern.

Finden Sie das Ganzemtls-demo.yamlbis zu diesem Punkt fürReferenz hier.

Teil II: mTLS aktivieren

Das gegenseitige TLS-System (mTLS) erfordert die Verwendung digitaler Zertifikate. Der erste Schritt besteht darin, sicherzustellen, dass der Cluster über eine Entität verfügt, die für die Verwaltung von Zertifikaten zuständig ist. Verwenden Sie in diesem BeispielZertifikatsmanager.

Zum Zeitpunkt der Veröffentlichung dieses Handbuchs ist die neueste Cert-Manager-Version verfügbar1.6.1. Befolgen Sie den Installationsprozess für diese Version, wie in beschriebenCert-Manager-Installationsdokumente.

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml

Führen Sie Folgendes aus, um zu überprüfen, ob der Zertifikatsmanager installiert und betriebsbereit ist:

Kubectl-Rollout-Status Bereitstellung/Zertifikatsmanager -n Zertifikatsmanager# cert-manager sollte erfolgreich eingeführt werden

Sobald Cert-Manager auf dem Cluster installiert und betriebsbereit ist, fahren Sie mit dem nächsten Schritt der Definition der erforderlichen Komponenten für mTLS fort.

Konzentrieren Sie sich auf die Erstellung von Komponenten, die für die private Public Key Infrastructure (PKI) erforderlich sind. In diesem Fall,Privatgeländebezieht sich auf Komponenten innerhalb eines internen oder nicht öffentlichen Systems, die über verschlüsselte Kanäle unter Verwendung öffentlicher/privater Schlüssel und digitaler Zertifikate interagieren. Unsere Clientanwendung und der interne Redis-Server können als „privat“ betrachtet werden, da der Datenverkehr zwischen ihnen niemals die Grenzen des Clusters verlässt.

Für gegenseitiges TLS zwischen Server und Client müssen Sie die Komponentenzertifikate bereitstellen. Insbesondere benötigen Sie ein Serverzertifikat, ein Clientzertifikat und ein Zertifikat der Zertifizierungsstelle (CA). Die Zertifikate und die Behörden, die diese Zertifikate innerhalb eines Kubernetes-Clusters ausstellen, werden vom Cert-Manager verwaltet. Die endgültige Zertifikatskette sieht folgendermaßen aus:

„Leaf“-Zertifikate sind Server- und Client-Zertifikate. Das Serverzertifikat wird Redis zur Verfügung gestellt. Das Client-Zertifikat für die Client-Anwendung.

So sieht die endgültige Vereinbarung aus:

Beginnen Sie mit der Erstellung Ihres ersten ZertifikatsmanagersAusstellerbenutzerdefinierte Ressource. EinAusstellerist verantwortlich für die Abwicklung des Prozesses der Beantragung und anschließenden Ausstellung von Zertifikaten an Interessenten. Der ersteAusstellerDas von Ihnen erstellte Zertifikat ist für die Ausstellung eines Stammzertifikats verantwortlich. Ein Stammzertifikat fungiert als vertrauenswürdiges Zertifikat einer Zertifizierungsstelle (CA) innerhalb des mTLS-Schemas.

WICHTIG: Fügen Sie diese Definition direkt nach dem hinzumtls-demoNamespace-Definition inmtls-demo.yaml.

---apiVersion: cert-manager.io/v1Art: AusstellerMetadaten: Name: Bootstrap-Aussteller Namensraum: mtls-demospez: selbstsigniert: { }

kubectl apply -f mtls-demo.yaml# Stellen Sie sicher, dass der Issuer einsatzbereit istkubectlWarten--für=Zustand=Bereit=Echter Aussteller Bootstrap-Aussteller -n mtls-demo# Sie sollten die Meldung „Bedingung erfüllt“ erhalten.

Für diese Demonstration ist der Typ vonAusstellerIstSelbstsigniert, aber Sie können dies in andere vom Zertifikatsmanager unterstützte Typen ändern, zCAAusstellerfür Produktionszwecke.

Als nächstes definieren Sie die WurzelZertifikatfür den Namensraum. Alle Komponenten verlassen sich auf dieses als vertrauenswürdige Stammzertifikat:

Fügen Sie diese Definition direkt nach dem Bootstrap-Aussteller hinzumtls-demo.yaml

---apiVersion: cert-manager.io/v1Art: ZertifikatMetadaten: Name: Root-Zertifikat Namensraum: mtls-demospez: Köder: WAHR geheimerName: Root-Zertifikat gemeinsamen Namen: „Root-Zertifikat“ Privat Schlüssel: Algorithmus: RSA Größe: 4096 Codierung: PKCS8 Emittenten-Ref: Name: Bootstrap-Aussteller Art: Aussteller

kubectl apply -f mtls-demo.yaml# Überprüfen Sie, ob das Zertifikat ausgestellt wurdekubectlWarten--für=Zustand=Bereit=True cert root-certificate -n mtls-demo# Sie sollten die Meldung „Bedingung erfüllt“ erhalten.

Beachten Sie, dass dieAusstellerfür dieses Zertifikat ist der BootstrapAusstelleraus dem vorherigen Schritt. Ohne die InitialeAussteller, gäbe es niemanden, der das Stammzertifikat ausstellt.

Sie können nun die Wurzel definierenAussteller(nicht zu verwechseln mit unserem BootstrappingAussteller). Der UrsprungAusstellerist für die Ausstellung von Zertifikaten verantwortlich, die auf Server- oder Client-Nutzung ausgerichtet sind.

Fügen Sie diese Definition direkt nach dem Stamm hinzuZertifikatDefinition inmtls-demo.yaml

---apiVersion: cert-manager.io/v1Art: AusstellerMetadaten: Name: Root-Aussteller Namensraum: mtls-demospez: ca: geheimerName: Root-Zertifikat

kubectl apply -f mtls-demo.yaml# Stellen Sie sicher, dass der Issuer einsatzbereit ist.kubectlWarten--für=Zustand=Bereit=Echter Emittent root-issuer -n mtls-demo# Sie sollten die Meldung „Bedingung erfüllt“ erhalten.

Damit das gegenseitige TLS-System funktioniert, benötigen Parteien, die kommunizieren möchten, zwei Zertifikate. Der bereitstellende Dienst (d. h. Redis) benötigt ein „Serverzertifikat“, während alle Clients des Dienstes (d. h. die Spring Boot-App) ein „Clientzertifikat“ benötigen. Definieren Sie dazu beide Arten von Zertifikaten.

Zunächst müssen Sie ein Serverzertifikat definieren. Die TLS-Unterstützung in Redis (und in den meisten anderen Diensten) setzt den Start des Dienstes mit einem digitalen Zertifikat voraus (.crtDatei), privater Schlüssel (.TasteDatei) und CA-Zertifikat (.crtDatei) zur Verfügung gestellt. KasseDokumentation zur Redis TLS-Unterstützungfür Details.

Fügen Sie diese Definition direkt nach dem Stamm hinzuAusstellerDefinition inmtls-demo.yaml.

---apiVersion: cert-manager.io/v1Art: ZertifikatMetadaten: Name: Redis-Server-Zertifikat Namensraum: mtls-demospez: geheimerName: Redis-Server-Zertifikat Privat Schlüssel: Algorithmus: RSA Codierung: PKCS8 Größe: 4096 gemeinsamen Namen: „Redis-Demo“ Verwendet: -Server-Authentifizierung -Schlüsselverschlüsselung -Digitale Unterschrift Emittenten-Ref: Name: Root-Aussteller Art: Aussteller

kubectl apply -f mtls-demo.yaml# Überprüfen Sie, ob das Zertifikat ausgestellt wurde.kubectlWarten--für=Zustand=Bereit=True cert redis-server-certificate -n mtls-demo# Sie sollten die Meldung „Bedingung erfüllt“ erhalten.

Sie haben erfolgreich ein Serverzertifikat für Redis erhalten und können mit der Erstellung eines Clientzertifikats zur Verwendung durch Redis-Clients fortfahren.

Fügen Sie diese Definition direkt nach der Definition des Serverzertifikats hinzumtls-demo.yaml.

---apiVersion: v1Art: GeheimnisMetadaten: Name: Redis-Client-Zertifikat-Keystore-Passwort Namensraum: mtls-demoDaten: Passwort: cGFzc3dvcmQxMjM= # "Passwort123"---apiVersion: cert-manager.io/v1Art: ZertifikatMetadaten: Name: Redis-Client-Zertifikat Namensraum: mtls-demospez: geheimerName: Redis-Client-Zertifikat Privat Schlüssel: Algorithmus: RSA Codierung: PKCS8 Größe: 4096 gemeinsamen Namen: „Redis-Demo“ Verwendet: -Client-Authentifizierung -Schlüsselverschlüsselung -Digitale Unterschrift Emittenten-Ref: Name: Root-Aussteller Art: Aussteller Schlüsselspeicher: pkcs12: erstellen: WAHR PasswortGeheimnisRef: Name: Redis-Client-Zertifikat-Keystore-Passwort Taste: Passwort

kubectl apply -f mtls-demo.yaml# Überprüfen Sie, ob das Zertifikat ausgestellt wurde.kubectlWarten--für=Zustand=Bereit=True cert redis-client-certificate -n mtls-demo# Sie sollten die Meldung „Bedingung erfüllt“ erhalten.

Sie haben jetzt ein Client-Zertifikat erhalten, das mit jedem Redis-Client verwendet werden kann, der TLS-fähig ist. Oben definieren Sie eine geheime Ressource, die ein Passwort für den PKCS#12-Keystore und den Truststore enthält, den der Zertifikatsmanager im Rahmen seines Zertifikatsausstellungsprozesses erstellen wird. Sie benötigen einen PKCS#12-Keystore und einen Truststore, da der Client JVM-basiert ist und das Zertifikat für den Client und das CA-Zertifikat in diesen Speichern enthalten sind und von der JVM zur Laufzeit verwendet werden. Keystores enthalten private Zertifikate und Truststores enthalten öffentlich verfügbare Zertifikate wie CAcertificates.

Sie sind jetzt bereit, die TLS-Unterstützung im Redis-Server zu aktivieren, aber sehen Sie sich zunächst noch einmal die Bereitstellungsdefinition des Redis-Servers anRedis-Dokumentation zur TLS-Unterstützung, müssen Sie Redis mitteilen, dass TLS aktiviert ist, und das Serverzertifikat, den privaten Schlüssel des Servers und das CA-Zertifikat bereitstellen.

Beispielsweise kann Redis im TLS-Modus über die Befehlszeile gestartet werden:

# Das unten angegebene Zertifikat, der Schlüssel und das CA-Zertifikat sind Beispiele. Sie haben diese Dateien nicht lokal.redis-server --tls-port6379--Hafen0 \--tls-cert-file ./redis.crt\--tls-key-file ./redis.key\--tls-ca-cert-file ./ca.crt

Übersetzen Sie dieses Beispiel nun in Begriffe der Bereitstellungsdefinition.

Ersetzen Sie die vorhandene Definition vonRedis-ServerEinsatz inmtls-demo.yaml.

apiVersion: apps/v1Art: EinsatzMetadaten: Namensraum: mtls-demo Name: Redis-Serverspez: Repliken: 1 Wähler: matchLabels: Name: Redis-Server Vorlage: Metadaten: Etiketten: Name: Redis-Server spez: Bände: -Name: Zertifikate Geheimnis: geheimerName: Redis-Server-Zertifikat Behälter: -Name: Redis-Server Bild: bitnami/redis:6.2.6 Häfen: -ContainerPort: 6379 volumeMounts: -mountPath: /Zertifikate Name: Zertifikate env: -Name: ALLOW_EMPTY_PASSWORD Wert: "Ja" -Name: REDIS_TLS_ENABLED Wert: "Ja" -Name: REDIS_TLS_PORT Wert: „6379“ -Name: REDIS_TLS_CERT_FILE Wert: „/certs/tls.crt“ -Name: REDIS_TLS_KEY_FILE Wert: „/certs/tls.key“ -Name: REDIS_TLS_CA_FILE Wert: „/certs/ca.crt“

kubectl apply -f mtls-demo.yaml

Mounten Sie eine geheime Serverzertifikat-Ressource als Volume auf dem Redis-Pod und platzieren Sie sie darin/ZertifikateVerzeichnis auf dem Pod. Die Secret-Ressource ist eine Referenz auf das Redis-Serverzertifikat und enthält die folgenden Dateien:

• tls.crt(das Serverzertifikat)
• tls.key(der private Schlüssel)
• ca.crt(das CA-Zertifikat).

Alle Dateien aus dem Secret werden im abgelegt/ZertifikateVerzeichnis.

Definieren Sie einige Umgebungsvariablen für den Container, die Redis anweisen, an den entsprechenden Speicherorten nach den Serverzertifikatdateien zu suchen.

Redis sollte nun im TLS-Modus gestartet werden. Sie können dies überprüfen, indem Sie den folgenden Befehl ausführen:

kubectlGeschäftsführerDeployment/redis-server -n mtls-demo – redis-cli ping

Sie sollten die folgende Meldung sehen:Fehler: Verbindung wurde vom Peer zurückgesetzt. Die Verbindung zu Redis kann nicht hergestellt werden, und das ist korrekt. Sie benötigen nun das Client-Zertifikat auf der Client-Seite (in diesem Fallredis-cli), um eine TLS-Verbindung ordnungsgemäß aufbauen zu können. Herstellen einer Verbindung mitredis-cliDie Verbindung zu einem TLS-fähigen Redis-Server ist eine Übung, die dem Leser überlassen bleibt, da der Schwerpunkt hier stattdessen auf der Aktivierung einer Client-Spring-Boot-Anwendung liegt.

Sie fahren nun damit fort, die Spring Boot Redis-Clientanwendung für die Verbindung mit TLS-fähigem Redis zu aktivieren.

Ersetzen Sie die vorhandene Bereitstellungsdefinition der Spring Boot Redis-Clientanwendung, um das Redisclient-Zertifikat einzufügen, das in einem vorherigen Schritt ausgestellt wurde. Erstellen Sie außerdem eine Secret-Ressource, um Java-VM-Optionen zu erfassen und die geladenen Zertifikate innerhalb der Laufzeit zu ändern.

Ersetzen Sie die vorhandene Definition vonSpring-Boot-Redis-Client-AppEinsatz inmtls-demo.yamlHinzufügenspring-boot-redis-client-app-java-optsGeheimnis vor der Bereitstellung.

---apiVersion: v1Art: GeheimnisMetadaten: Name: spring-boot-redis-client-app-java-opts Namensraum: mtls-demostringData: JAVA_OPTS: >--Djavax.net.ssl.keyStoreType=PKCS12-Djavax.net.ssl.keyStore=/certs/keystore.p12-Djavax.net.ssl.keyStorePassword=password123-Djavax.net.ssl.trustStoreType=PKCS12-Djavax.net.ssl.trustStore=/certs/truststore.p12-Djavax.net.ssl.trustStorePassword=password123 ---apiVersion: apps/v1Art: EinsatzMetadaten: Etiketten: App: Spring-Boot-Redis-Client-App Name: Spring-Boot-Redis-Client-App Namensraum: mtls-demospez: Repliken: 1 Wähler: matchLabels: App: Spring-Boot-Redis-Client-App Vorlage: Metadaten: Etiketten: App: Spring-Boot-Redis-Client-App spez: Bände: -Name: Kundenzertifikat Geheimnis: geheimerName: Redis-Client-Zertifikat Behälter: -Bild: ddubson/spring-boot-redis-mtls-demo:basic Name: Spring-Boot-Redis-Client-App volumeMounts: -mountPath: /Zertifikate Name: Kundenzertifikat env: -Name: SPRING_REDIS_HOST Wert: „Redis-Server“ -Name: SPRING_REDIS_PORT Wert: „6379“ -Name: SPRING_REDIS_SSL Wert: "WAHR" envFrom: -SecretRef: Name: spring-boot-redis-client-app-java-opts Häfen: -ContainerPort: 8080 Name: App-Port Protokoll: TCP livenessProbe: httpGet: Weg: /Aktuator/Gesundheit Hafen: App-Port BereitschaftProbe: httpGet: Weg: /Aktuator/Gesundheit Hafen: App-Port

kubectl apply -f mtls-demo.yaml

Hängen Sie die geheime Ressource des Redis-Client-Zertifikats als Volume im Anwendungs-Pod ein. Geben Sie die Pathas an/Zertifikate. Benachrichtigen Sie die Spring Data Redis-Bibliothek über die KonfigurationsumgebungsvariableSPRING_REDIS_SSLdass Redis TLS-Verbindungen akzeptiert. Der wichtigste Teil der Einführung des Redis-Client-Zertifikats und des CA-Zertifikats in die JVM der Anwendung ist die Injektion desspring-boot-redis-client-app-java-optsSecret als eine Reihe von Umgebungsvariablen, die eine einzelne enthaltenJAVA_OPTSMit der Umgebungsvariablen können wir VM-Optionen für die JVM definieren. Hier legen Sie festJava Secure Socket Extension (JSSE)Umgebungsvariablen:

• javax.net.ssl.keyStoreist der Container für private Zertifikate, da er das Redis-Clientzertifikat enthält (tls.crt).
• javax.net.ssl.trustStoreist der Container für öffentliche Zertifikate, da er das CAcertificate (ca.crt- unser Root-Zertifikat).

Beziehen aufReferenzhandbuch zur Java Secure Socket Extension (JSSE).Weitere Informationen zu Keystores und Truststores finden Sie hier.

cert-manager erstellt die Keystore- und Truststore-Dateien im Rahmen des Zertifikatsausstellungsprozesses im Handumdrehen, sodass Sie sie sofort nutzen können. Keystore- und Truststore-Passwörter liegen im Klartext vor. Das Verschleiern des Passworts ist nicht Gegenstand dieses Handbuchs, wird jedoch für Produktionsdefinitionen dringend empfohlen. Das im Klartext genannte Passwort muss mit dem Inhalt des Secrets übereinstimmenRedis-Client-Zertifikat-Keystore-Passwort.

Stellen Sie sicher, dass die Anwendung jetzt eine Verbindung zu einem TLS-fähigen Redis-Server hergestellt hat:

kubectl port-forward svc/spring-boot-redis-client-app 8080:8080 -n mtls-demo# In einem anderen Terminalfenster/Tabcurl -XGET http://localhost:8080/# Als Antwort sollten Sie eine zufällige UUID-Zeichenfolge erhalten.

Sie können nun die Portweiterleitung stoppen und mit den nächsten Schritten fortfahren.

⚠️ Warnung

Eine Einschränkung, die Sie beachten sollten, besteht darin, dass Sie einen expliziten Truststore über die VM-Option angeben und ihn an die JVM übergeben, da dies der Fall istüberschreibtder Standard-Truststore! Dies kann in Fällen zu einem Problem werden, in denen Sie alle CA-Zertifikate aus dem Standardtruststore benötigen (normalerweise in$JAVA_HOME/lib/security/cacerts) UND ein benutzerdefinierter CA-Zertifikat-Truststore, der vom Zertifikatsmanager dynamisch ausgestellt wird. Lies dasTeil II Extended Cut: CA-Zertifikate mithilfe von Servicebindungen verwaltenWeitere Informationen finden Sie im Abschnitt.

Glückwunsch! Sie haben sichergestellt, dass der Datenverkehr innerhalb des Clusters zwischen Redis und der Clientanwendung auf TLS basiert und verschlüsselt ist.

Überspringen zuFinaleWenn Sie kein Interesse haben, lesen Sie den nächsten optionalen Abschnitt zu CA-Zertifikaten und JVM-Truststores.

Teil II (Erweiterter Schnitt): CA-Zertifikate mithilfe von Servicebindungen verwalten

Überspringen Sie diesen Abschnitt, wenn Ihre Clientanwendung kein Spring Boot- oder Docker-Image ist, das mit Cloud Native Buildpacks erstellt wurde.

Sie haben dafür gesorgt, dass die Clientanwendung über das gegenseitige TLS-Schema im Cluster mit Redis kommuniziert. Exzellent!

Dies ist ein zusätzlicher Abschnitt, der sich speziell mit dem Problem des Überschreibens des Standard-JVM-Truststores in der SpringBoot-Clientanwendung befasst, die mit Cloud Native Buildpacks erstellt wurde.

Um das Redis-Client-CA-Zertifikat zum vorhandenen Standard-JVM-Truststore von Cloud Native Buildpack-builtimage hinzuzufügen, erstellen Sie einLaufzeitdienstbindunginnerhalb des Containers und füllen Sie ihn mit dem CA-Zertifikat. So sieht das Design unserer Lösung aus:

Ersetzen Sie die vorhandene Definition vonSpring-Boot-Redis-Client-AppEinsatz inmtls-demo.yaml.Hinzufügencacert-service-binding-typeConfigMap und ändern Sie vorhandenespring-boot-redis-client-app-java-optsGeheimnis.

---apiVersion: v1Art: ConfigMapMetadaten: Name: cacert-service-binding-type Namensraum: mtls-demoDaten: Typ: „ca-Zertifikate“---apiVersion: v1Art: GeheimnisMetadaten: Name: spring-boot-redis-client-app-java-opts Namensraum: mtls-demostringData: JAVA_OPTS: >--Djavax.net.ssl.keyStoreType=PKCS12-Djavax.net.ssl.keyStore=/certs/keystore.p12-Djavax.net.ssl.keyStorePassword=password123 ---apiVersion: apps/v1Art: EinsatzMetadaten: Etiketten: App: Spring-Boot-Redis-Client-App Name: Spring-Boot-Redis-Client-App Namensraum: mtls-demospez: Repliken: 1 Wähler: matchLabels: App: Spring-Boot-Redis-Client-App Vorlage: Metadaten: Etiketten: App: Spring-Boot-Redis-Client-App spez: Bände: -Name: Kundenzertifikat Geheimnis: geheimerName: Redis-Client-Zertifikat -Name: cacert-service-binding projiziert: Quellen: -configMap: Name: cacert-service-binding-type -Geheimnis: Name: Redis-Client-Zertifikat Artikel: -Taste: ca.crt Weg: ca.crt Behälter: -Bild: ddubson/spring-boot-redis-mtls-demo:basic Name: Spring-Boot-Redis-Client-App volumeMounts: -mountPath: /Zertifikate Name: Kundenzertifikat -mountPath: /bindings/cacert-service-binding Name: cacert-service-binding env: -Name: SERVICE_BINDING_ROOT Wert: „/Bindungen“ -Name: SPRING_REDIS_HOST Wert: „Redis-Server“ -Name: SPRING_REDIS_PORT Wert: „6379“ -Name: SPRING_REDIS_SSL Wert: "WAHR" envFrom: -SecretRef: Name: spring-boot-redis-client-app-java-opts Häfen: -ContainerPort: 8080 Name: App-Port Protokoll: TCP livenessProbe: httpGet: Weg: /Aktuator/Gesundheit Hafen: App-Port BereitschaftProbe: httpGet: Weg: /Aktuator/Gesundheit Hafen: App-Port

kubectl apply -f mtls-demo.yaml

Entfernen Sie alle VM-Optionen, die zuvor für den Truststore festgelegt wurdenspring-boot-redis-client-app-java-optsGeheime Ressource, die auf andere Weise mithilfe einer Servicebindung und eines projizierten Volumes geladen wird.

AServicebindungist ein strukturierter Ordner, der als Volume im Client-Anwendungs-Pod bereitgestellt wird. In diesem Fall enthält es eine Datei namensTypmit wörtlichem TextCA-Zertifikateweil Sie einen Servicebindungstyp für CA-Zertifikate verwenden und die Zertifikatsdatei (d. h.ca.crt). Ein ... kreierenSERVICE_BINDING_ROOTUmgebungsvariable, in der Sie das Stammverzeichnis aller Bindungen definieren. In diesem Fall ist es setto/BindungenVerzeichnis im Container.

Benutze einenProjiziertes Volumenum die erforderlichen Dateien in einer Verzeichnisstruktur mit den erforderlichen Dateien zusammenzufassen. Sie haben eine erstelltConfigMapeinen Schlüssel speichernTypmit WertCA-Zertifikateim projizierten Volumen als eine der Quellen zu definieren. Du hast auch das genommenca.crtDatei vonRedis-Client-Zertifikatund nutzte es als zweite Quelle für das geplante Volumen. Zusammen stellen diese Dateien eine einzelne Entität dar, die Sie in den Clientanwendungscontainer einbinden können.

So sieht der Satz von Servicebindungen als Dateibaum im Container aus:

/Bindungen/cacert-service-bindingca.crtTyp

Erstellen Sie für diese Demonstration nur eine Bindung mit dem Namencacert-service-binding. Der Service-Bindungsmechanismus des von Ihnen verwendeten Spring Boot-Images registriert das automatischCA-ZertifikateBindung und lädt das CA-Zertifikat in den Standard-JVM-Truststore.

Um zu überprüfen, ob der Service-Bindungsmechanismus funktioniert, führen Sie Folgendes aus:

Kubectl-Protokolle Deploy/spring-boot-redis-client-app -n mtls-demo|Kopf -n1# Beachten Sie, dass die Zeile im Protokoll lautet:# „1 zusätzliche(s) CA-Zertifikat(e) zum System-Truststore hinzugefügt“kubectl port-forward svc/spring-boot-redis-client-app 8080:8080 -n mtls-demo# In einem anderen Terminalfenster/Tabcurl -XGET http://localhost:8080/# Als Antwort sollten Sie eine zufällige UUID-Zeichenfolge erhalten.

Sie können die Portweiterleitung jetzt stoppen.

Dadurch wird überprüft, ob das Redis-Client-Zertifikat in den JVM-Truststore geladen ist und Sie wieder über eine TLS-Verbindung mit Redis kommunizieren können.

Finale

Die vollständigen Kubernetes-Ressourcendefinitionen für jeden Teil finden Sie hier:

• Teil I: Workflows erstellen
• Teil II: mTLS aktivieren(Erfordert, dass der Cert-Manager vorinstalliert ist.)
• Teil II (Erweiterter Schnitt): CA-Zertifikate mithilfe von Servicebindungen verwalten(Erfordert die Vorinstallation des Cert-Managers.)

Vergessen Sie abschließend nicht, Ihren Cluster zu bereinigen. Führen Sie Folgendes aus:

kubectl löscht den Namespace mtls-demokubectl delete -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml

Dadurch werden alle Bereitstellungen, Dienste und anderen spezifischen Konfigurationen entferntmtls-demoNamespace sowie die Cert-Manager-Installation aus dem Cluster.