Ein Unternehmen entwickelt einen Dienst, der eine End-to-End-Verschlüsselung während der Übertragung erfordert, sodass der Datenverkehr zwischen dem Client und dem Service-Backend nicht entschlüsselt wird. Der Dienst verwendet gRPC über TCP-Port 443 und muss Tausende gleichzeitiger Verbindungen unterstützen. Das Backend läuft auf einem Amazon EKS-Cluster, wobei der Kubernetes Cluster Autoscaler und der Horizontal Pod Autoscaler aktiviert sind. Mutual TLS ist für die Zwei-Wege-Authentifizierung zwischen Clients und dem Backend erforderlich. Welche Lösung erfüllt diese Anforderungen?

Die korrekte Lösung ist die Bereitstellung eines Network Load Balancers (NLB) mit einem TCP-Listener auf Port 443, der den Datenverkehr direkt an die Pod-IP-Adressen weiterleitet. Dies ermöglicht eine End-to-End-Verschlüsselung, da der NLB den Datenverkehr auf Schicht 4 (TCP) weiterleitet, ohne ihn zu entschlüsseln. Mutual TLS (mTLS) kann so direkt zwischen Client und Backend-Pod abgewickelt werden. Der AWS Load Balancer Controller automatisiert die Integration des NLB mit dem EKS-Cluster und der Pod-Skalierung. Ein Application Load Balancer (ALB) ist ungeeignet, da er bei HTTPS-Listenern eine TLS-Terminierung am Load Balancer erzwingen würde, was die Anforderung der End-to-End-Verschlüsselung verletzt. Zudem unterstützt der ALB mTLS nicht nativ für die Weiterleitung an Backend-Pods, ohne die TLS-Sitzung selbst zu terminieren. Die Registrierung der Auto Scaling-Gruppe der EKS Managed Node Group als Zielgruppe ist ebenfalls falsch, da der Datenverkehr an die Knoten und nicht direkt an die Pods geleitet würde, was die Pod-IP-Adressen für die Weiterleitung ignoriert und die Skalierungsfähigkeit und das Routing innerhalb des Clusters beeinträchtigt.