Nel caso Cuttlefish su Amazon EKS descritto da AWS, Envoy Gateway gestisce il traffico TCP di ADB verso i pod, con un gateway dedicato in ogni namespace tenant. Una guida AWS separata usa invece NGINX Ingress per verificare i certificati dei client nelle connessioni HTTPS dirette alle applicazioni. mTLS, cioè TLS reciproco, autentica entrambe le estremità della connessione tramite certificati. AWS ha pubblicato il caso Cuttlefish il 6 novembre 2026; la guida AWS per NGINX Ingress descrive un flusso diverso.
Per scegliere il modello, parti dal traffico da proteggere: TCP verso i pod nel caso Envoy, HTTPS verso un’applicazione nel modello NGINX.
Envoy gestisce ADB nel namespace del tenant
ADB, l’Android Debug Bridge, comunica con i dispositivi Cuttlefish tramite TCP. Nell’architettura descritta da AWS, una CLI personalizzata contatta un’API di autorizzazione; dopo aver verificato il token JWT dell’identity provider aziendale e l’assegnazione dell’utente al namespace, l’API restituisce i dati di connessione e un certificato limitato a quel namespace. Il certificato identifica il namespace nella connessione mTLS, mentre il JWT identifica l’utente.
Ogni namespace tenant ospita un’istanza di Envoy Gateway, che instrada il traffico solo verso i pod dello stesso namespace. La parte WebRTC segue un percorso distinto: Amazon Kinesis Video Streams fornisce il relay TURN, mentre Cuttlefish mantiene il proprio server di segnalazione predefinito. AWS riferisce che questa scelta ha eliminato il servizio personalizzato che trasformava i token dell’identity provider in credenziali TURN e la gestione manuale dei server TURN.
Prerequisiti e rinnovo dei certificati
Il modello presuppone isolamento dei namespace, autorizzazioni RBAC circoscritte e una NetworkPolicy con negazione predefinita in ciascun namespace tenant. Senza queste regole di rete, il traffico può aggirare il gateway. Servono inoltre la verifica del JWT da parte dell’API personalizzata, AWS Private CA, cert-manager e il relativo plugin issuer per AWS.
AWS descrive certificati con validità di 12 ore e una finestra di rinnovo di 4 ore. In questa configurazione cert-manager avvia normalmente il rinnovo dopo due terzi della validità, cioè trascorse 8 ore. Envoy Gateway riceve i certificati aggiornati tramite SDS senza riavviare il pod.
Per registrare le attività, l’API personalizzata annota identità autenticata, namespace e orario. Se più utenti condividono un namespace, AWS indica certificati distinti per utente quando serve un’attribuzione più precisa: il soggetto del certificato descritto identifica il namespace, non il singolo utente.
Il confine di mTLS e la differenza con NGINX
Nel caso Cuttlefish, mTLS termina su Envoy: il tratto da Envoy al pod non è cifrato tramite mTLS. La NetworkPolicy limita quali componenti possono raggiungere la porta ADB; per estendere la protezione mTLS fino al pod, AWS indica sidecar o certificati a livello di pod. Il percorso dati ADB non usa AWS WAF nell’architettura descritta; l’API REST, invece, è protetta da HTTPS e AWS WAF.
| Aspetto | Envoy Gateway nel caso Cuttlefish | NGINX Ingress nella guida AWS |
| Traffico | Proxy TCP per ADB verso i pod di un namespace tenant | Verifica dei certificati client per HTTPS diretto alle applicazioni |
| Configurazione | Un’istanza Envoy Gateway per namespace tenant, con mTLS e NetworkPolicy | Annotazioni Ingress e un Secret Kubernetes con certificato del server, chiave privata e certificato CA |
| Certificati | AWS Private CA con cert-manager e il plugin issuer AWS; certificati limitati al namespace e di breve durata | L’esempio usa certificati autofirmati ed è destinato ai test; per la produzione AWS raccomanda AWS Private CA o una PKI esistente |
| Confine | mTLS termina su Envoy; il tratto Envoy-pod non usa mTLS | È un esempio per HTTPS Ingress di applicazioni, non un proxy TCP per ADB |
L’esempio NGINX attiva la verifica del certificato client tramite l’annotazione nginx.ingress.kubernetes.io/auth-tls-verify-client: "on". Nei test descritti dalla guida, una richiesta senza certificato client riceve una risposta HTTP 400; con il certificato, l’applicazione restituisce la propria risposta.
I tempi e i risultati riportati da AWS
Per il precedente percorso attraverso un bastion a due hop, AWS riporta installazioni di applicazioni da 3 a 4 minuti e andata e ritorno dei comandi ADB da 1 a 2 secondi. Nel percorso con Envoy, AWS riferisce installazioni inferiori a 30 secondi e completamento dei comandi ADB in meno di 100 millisecondi. Separatamente, riporta una latenza del gateway inferiore a 50 millisecondi rispetto alla configurazione locale: è una misura distinta dal tempo di completamento dei comandi.
Per WebRTC, AWS riferisce connessioni stabili durante i picchi di utilizzo e l’assenza di aggiornamenti manuali delle regole di routing quando i pod si spostano tra zone di disponibilità. Indica inoltre che i costi di Kinesis Video Streams dipendono dai canali di segnalazione attivi, dai messaggi di segnalazione e dai minuti di streaming TURN.
