Le mTLS, ou TLS mutuel, authentifie les deux extrémités d’une connexion. Dans le cas Cuttlefish sur Amazon EKS qu’AWS a publié le 6 novembre 2026, Envoy sert de proxy TCP pour les connexions ADB limitées à un espace de noms Kubernetes ; l’exemple NGINX Ingress distinct d’AWS vérifie les certificats clients pour des applications accessibles en HTTPS. AWS décrit les deux modèles dans ses études et guides techniques. Pour choisir, partez donc du type de trafic à protéger.
Pour l’accès TCP à ADB, le modèle décrit par AWS passe par Envoy dans chaque espace de noms ; pour l’HTTPS applicatif, son exemple utilise NGINX Ingress.
Comment le modèle Envoy achemine les connexions ADB
Cuttlefish est un appareil Android virtuel configurable. Dans le déploiement décrit par AWS, une interface en ligne de commande appelle une API personnalisée. Celle-ci vérifie le jeton JWT de l’utilisateur et son affectation à un espace de noms, puis renvoie par HTTPS les paramètres de connexion et un certificat associé à cet espace. Une passerelle Envoy dans cet espace achemine ensuite le trafic TCP d’ADB vers les pods qui s’y trouvent.
Le JWT rattache la demande à l’utilisateur ; le certificat de courte durée identifie l’espace de noms pour la connexion mTLS. Ce découpage compte dans un environnement multi-tenant : chaque passerelle est limitée aux pods de son espace, plutôt que de servir de point d’entrée commun à tous les locataires.
AWS décrit aussi une voie distincte pour les médias WebRTC. Amazon Kinesis Video Streams fournit le relais TURN, qui relaie le trafic lorsque les pairs WebRTC ne peuvent pas communiquer directement. Dans ce déploiement, ce service a remplacé STUNner, auparavant autogéré. Il ne s’agit pas de la passerelle ADB.
Prérequis réseau et cycle de vie des certificats
Le modèle repose sur l’isolation des espaces de noms, des autorisations RBAC limitées et des règles NetworkPolicy en refus par défaut dans chaque espace. AWS précise que, sans ces règles, le trafic peut contourner la passerelle. L’API personnalisée doit également valider les JWT ; l’émission des certificats fait appel à AWS Private CA, à cert-manager et au module d’émission AWS pour cert-manager.
Dans le profil décrit par AWS, les certificats durent 12 heures et leur renouvellement s’inscrit dans une fenêtre de 4 heures. cert-manager demande de nouveaux certificats, puis Envoy Gateway reçoit les certificats renouvelés par SDS, le mécanisme de distribution des secrets, sans redémarrage du pod. Le nom commun du certificat suit la convention <user-namespace>.eks.internal ; AWS recommande d’éviter tout conflit avec le DNS de l’organisation.
Le certificat décrit identifie l’espace de noms, pas chaque utilisateur. Si plusieurs personnes partagent le même espace et qu’une attribution fine des actions est nécessaire, AWS indique qu’il faut des certificats individuels par utilisateur.
Où le mTLS s’arrête, et quand choisir NGINX Ingress
Dans le cas Envoy, le mTLS prend fin sur la passerelle. Le trajet d’Envoy au pod n’est donc pas chiffré par mTLS. Une NetworkPolicy limite les composants autorisés à joindre le port ADB ; AWS cite aussi les certificats au niveau des pods ou des sidecars comme options pour étendre le mTLS jusqu’aux charges de travail. Dans cette architecture, le chemin des données ADB n’est pas derrière AWS WAF ; l’API REST, elle, passe par HTTPS et AWS WAF.
| Dimension | Envoy Gateway dans le cas Cuttlefish | NGINX Ingress dans l’exemple AWS |
| Trafic visé | Connexions TCP d’ADB vers des pods | Trafic HTTPS vers une application |
| Rôle | Proxy limité aux pods d’un espace de noms | Vérification du certificat client à l’entrée de l’application |
| Certificats | AWS Private CA avec cert-manager et son module d’émission AWS | L’exemple utilise des certificats autosignés pour les tests |
| Point à retenir | Le mTLS s’arrête à Envoy | AWS recommande AWS Private CA ou une PKI existante en production |
L’exemple NGINX Ingress d’AWS configure la vérification du certificat client avec des annotations Ingress et un secret Kubernetes contenant les éléments de certificat. Le test renvoie une erreur HTTP 400 sans certificat client et la réponse de l’application lorsqu’un certificat est présenté. Les certificats autosignés de la procédure sont réservés aux clusters de test ; pour la production, AWS recommande AWS Private CA ou une infrastructure à clés publiques existante.
Les résultats rapportés par AWS
AWS compare son nouveau chemin Envoy à un ancien parcours passant par deux sauts via un bastion. Pour l’installation d’applications, AWS rapporte un passage de 3 à 4 minutes à moins de 30 secondes. Pour les commandes ADB, l’étude indique auparavant 1 à 2 secondes par aller-retour, puis moins de 100 ms pour leur exécution avec Envoy.
AWS rapporte séparément une latence de passerelle inférieure à 50 ms par rapport à une configuration locale. Cette mesure ne correspond pas au temps total d’exécution d’une commande ADB. Pour WebRTC, AWS indique que les connexions sont restées stables pendant les périodes de forte utilisation et que les déplacements de pods entre zones de disponibilité n’ont pas nécessité de mises à jour manuelles des règles de routage.
