vSphere with Tanzu und NSX Advanced Load Balancer Integration mit Private CA

Ab VMware vSphere 8.0 Update 2 ist es möglich, vSphere with Tanzu mit VMware NSX als Networking Stack und VMware NSX Advanced Load Balancer (ALB) als integrierten L4 Load Balancer bereitzustellen. Darüber hinaus kann der NSX Advanced Load Balancer auch als L7 Ingress (AKO) Controller verwendet werden, um zusätzliche Enterprise-Features zur Verfügung zu stellen, wie bspw. Container- und App-Security mit WAF, real-time Application Performance Monitoring, Network & End Users Analytics/Insights uvm.

Dadurch ist es möglich, klassische L4/L7 Load Balancing Services bereitzustellen und parallel dazu auch Microservice-Anforderungen für Kubernetes Plattformen zu berücksichtigen. So lassen sich sämtliche NSX ALB Service Engine (Dataplane Komponenten, welche das effektive Load Balancing übernimmt) Instanzen, ob für Load Balanacing von virtuellen Maschinen oder Kuberentes basierte Workloads, in einem zentralen UI/Plattform verwalten.

Das Problem

Bei einem kürzlich durchgeführten Tanzu-Projekt, das auf vSphere 8.0 Update 2, NSX 4.1.2.1 und NSX ALB 22.1.5 basierte, stiessen wir auf ein Problem, das uns daran hinderte, den Supervisor Cluster zu initialisieren. Als wir versuchten, den Supervisor Cluster zu aktivieren, trat während der Workload Network Konfigurationsphase ein Timeout-Problem auf.

Als wir die NSX ALB-Konfiguration überprüften, stellten wir fest, dass kein einziges Objekt erstellt und auch keine entsprechenden Events in den Protokollen generiert wurden.

Daraufhin überprüften wir die NCP-Protokolle und fanden folgende Einträge:

[ncp GreenThread-125 W] nsx_ujo.ncp.nsx.policy.ako_bootstrap_service Unexpected exception from NSX manager when acquiring AVI auth token: Unexpected error from backend manager (['nsx-mgr-01:443', 'nsx-mgr-01a:443', 'nsx-mgr-01b:443', 'nsx-mgr-01c:443']) for PUT policy/api/v1/infra/alb-auth-token: Error: I/O error on GET request for https://192.168.100.33/api/user: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.

[ncp GreenThread-125 W] nsx_ujo.ncp.nsx.policy.ako_bootstrap_service get_avi_auth_token failed, cause: Failed to get Avi auth token: Unexpected error from backend manager (['nsx-mgr-01:443', 'nsx-mgr-01a:443', 'nsx-mgr-01b:443', 'nsx-mgr-01c:443']) for PUT policy/api/v1/infra/alb-auth-token: Error: I/O error on GET request for https://192.168.100.33/api/user: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain., args: (), kwargs: {}

[ncp GreenThread-125 I] nsx_ujo.common.controller AviSecretController worker 1 failed to sync Bootstrap due to retryable exception: Failed to get Avi auth token: Unexpected error from backend manager (['nsx-mgr-01:443', 'nsx-mgr-01a:443', 'nsx-mgr-01b:443', 'nsx-mgr-01c:443']) for PUT policy/api/v1/infra/alb-auth-token: Error: I/O error on GET request for https://192.168.100.33/api/user: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.

Es schien, als würde dies mit dem NSX Advanced Load Balancer Registrierungsprozess zusammenhängen, bei dem der NSX ALB Controller Cluster beim NSX Manager Cluster registriert (Link) wird.

Vor allem der Eintrag […]PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain[…] verwies auf ein klares Zertifikatsproblem, das so allerdings nicht direkt nachvollzogen werden konnte, da im NSX Certificate Trust Store die Private PKI/CA Zertifikate hinterlegt waren.

Die Lösung

Tatsächlich ist es so, dass der JVM (Java Virtual Machine) Prozess auf den NSX Manager Nodes einen eigenen Certificate Authority Trust Store besitzt, in welchem nur Public CAs geführt werden. Wenn man nun dem NSX ALB ein Zertifikat von einer Private PKI/CA ausstellt, dann kommt kein Vertrauensverhältnis zustande, da diese Private CA nicht im JVM Trust Store vorhanden ist.

VMware lieferte darauf hin einen konkreten Lösungvorschlag, bei welchem man die Private CAs in den JVM Trust Store importieren musste. Dazu muss man folgende Befehle sequentiell auf jedem NSX Manager ausführen:

keytool -importcert -alias <private-Root-CA> -keystore /usr/java/jre/lib/security/cacerts -storepass changeit -file <path-to-root-ca-cert>
keytool -importcert -alias <private-Intermediate-CA> -keystore /usr/java/jre/lib/security/cacerts -storepass changeit -file <path-to-intermediate-ca-cert>
sudo cp <path-to-root-ca-cert> /usr/local/share/ca-certificates/
sudo cp <path-to-intermediate-ca-cert> /usr/local/share/ca-certificates/
sudo update-ca-certificates
service proton restart

Nach dem wir diese Anpassungen vorgenommen haben, konnten wir den Supervisor Cluster erfolgreich initiieren. Dazu mussten wir das aktuelle Deployment abbrechen (Disable Supervisor) und neu initiieren.

Anmerkung(en)

[Update] 05.02.2024: Mittlerweise wurde die Dokumentation entsprechend aktualisiert und verweist auf diese Besonderheit hinsichtlich JVM Trust Store und Private CA ausgestellten Zertifikaten.