Voor AWS’ Cuttlefish-omgeving op Amazon EKS past Envoy bij mTLS-beveiligde TCP-toegang via Android Debug Bridge (ADB) naar pods. AWS’ aparte NGINX Ingress-voorbeeld behandelt clientcertificaatcontrole voor HTTPS-applicaties. De keuze hangt dus af van het verkeer dat je wilt beveiligen. AWS publiceerde de Cuttlefish-case op 6 november 2026; de migratie zelf dateerde het niet. AWS’ beschrijving van de Cuttlefish-architectuur
Kies het gatewaypatroon op basis van het verkeer: Envoy voor ADB via TCP naar pods, NGINX Ingress voor HTTPS-applicaties.
Envoy routeert ADB-verkeer naar pods per namespace
mTLS, oftewel wederzijdse TLS-authenticatie, laat beide kanten van een verbinding hun identiteit met certificaten aantonen. In AWS’ Cuttlefish-opzet staat per tenantnamespace een Envoy Gateway. Die gateway routeert ADB-verkeer alleen naar pods in die namespace.
De verbinding begint bij een aangepaste CLI. Een aangepaste API controleert het JWT-token van de gebruiker en diens toewijzing aan een namespace. Daarna stuurt de API via HTTPS de verbindingsgegevens en een kortlopend certificaat terug. Het JWT koppelt de gebruiker aan de juiste namespace; het certificaat geeft de mTLS-verbinding de identiteit van die namespace.
Voor deze opzet noemt AWS namespace-isolatie, afgebakende RBAC-rechten en standaard weigerende NetworkPolicies als voorwaarden. Zonder die netwerkregels kan verkeer de gateway omzeilen. Ook gebruikt het ontwerp AWS Private CA, cert-manager en de AWS issuer-plugin voor cert-manager.
Certificaten vernieuwen en de vertrouwensgrens
AWS beschrijft certificaten met een geldigheid van 12 uur en een vernieuwingsvenster van 4 uur. cert-manager begint normaal gesproken op twee derde van de geldigheidsduur met vernieuwen. Envoy Gateway ontvangt de nieuwe certificaatgegevens via SDS, zonder dat een pod opnieuw hoeft te starten. De certificaatnaam volgt de conventie <user-namespace>.eks.internal; AWS waarschuwt om die interne naam niet te laten botsen met de DNS-namen van de organisatie.
mTLS eindigt bij Envoy. De verbinding van Envoy naar de pod is in deze opzet dus niet met mTLS versleuteld. Een NetworkPolicy beperkt welke componenten de ADB-poort kunnen bereiken; AWS noemt sidecars of certificaten op podniveau als mogelijkheden wanneer ook die verbinding mTLS-beveiliging nodig heeft. Het ADB-verkeer heeft in de beschreven architectuur geen AWS WAF-bescherming. De aparte REST-API staat wel achter HTTPS en AWS WAF.
Envoy voor ADB en NGINX voor HTTPS
AWS’ Cuttlefish-case gebruikt Envoy als TCP-proxy voor ADB-toegang tot pods. De afzonderlijke NGINX-richtlijn gaat over clientcertificaatcontrole voor HTTPS-applicaties via Kubernetes Ingress. AWS’ NGINX Ingress-richtlijn gebruikt Ingress-instellingen en een Kubernetes Secret met certificaatmateriaal.
| Kenmerk | Envoy Gateway in de Cuttlefish-case | NGINX Ingress in de AWS-richtlijn |
| Verkeer | TCP-verkeer voor ADB naar pods | HTTPS-verkeer naar een applicatie |
| Rol van de gateway | Een Envoy Gateway per tenantnamespace routeert naar pods in die namespace | NGINX Ingress controleert het clientcertificaat voor applicatieverkeer |
| Certificaten | AWS Private CA met cert-manager en de AWS issuer-plugin; kortlopende namespacecertificaten | Het voorbeeld gebruikt zelfondertekende certificaten voor tests; voor productie raadt AWS AWS Private CA of een bestaande PKI aan |
| Einde van mTLS | Bij Envoy; de verbinding naar de pod is niet met mTLS versleuteld | Clientcertificaatcontrole voor HTTPS Ingress |
De NGINX-richtlijn is daarmee een ander patroon dan de namespacegebonden TCP-proxy voor ADB. De zelfondertekende certificaten in het NGINX-voorbeeld zijn bedoeld voor testclusters, niet voor productie.
Resultaten die AWS rapporteert
AWS rapporteert dat applicaties via de eerdere bastionverbinding 3–4 minuten nodig hadden om te installeren en dat een ADB-opdracht daar 1–2 seconden per heen-en-terugreis duurde. In de Envoy-opzet duurde een installatie volgens AWS minder dan 30 seconden en werd een ADB-opdracht in minder dan 100 ms voltooid. AWS rapporteert daarnaast minder dan 50 ms gatewaylatentie ten opzichte van een lokale Android-opstelling. Dat is een afzonderlijke meting, niet de totale duur van een ADB-opdracht.
Voor WebRTC-media gebruikte de beschreven architectuur Amazon Kinesis Video Streams als beheerde TURN-relay in plaats van de zelf beheerde STUNner-opzet. AWS schrijft dat dit de eigen tokenuitwisselingsdienst voor TURN-gegevens en het handmatige onderhoud van TURN-servers overbodig maakte. Het bedrijf meldt ook stabiele WebRTC-verbindingen tijdens piekgebruik en geen handmatige routeaanpassingen nadat pods tussen Availability Zones waren verplaatst.
