W opisanym przez AWS wdrożeniu Cuttlefish w Amazon EKS brama Envoy obsługuje ruch TCP z Android Debug Bridge (ADB) do podów w obrębie przestrzeni nazw. Osobny przykład AWS z NGINX Ingress dotyczy uwierzytelniania certyfikatem klienta w ruchu HTTPS do aplikacji. mTLS, czyli wzajemne uwierzytelnianie połączenia TLS, sprawdza tożsamość obu stron.
Przy wyborze wzorca zacznij od rodzaju ruchu: TCP do podów prowadzi w tym przypadku przez Envoy, a HTTPS do aplikacji przez Ingress NGINX.
Jak Envoy kieruje połączenia ADB w Amazon EKS
AWS opisało przypadek Cuttlefish 6 listopada 2026 r. Każda przestrzeń nazw dzierżawcy ma osobną instancję Envoy Gateway, która kieruje połączenia ADB wyłącznie do podów w tej przestrzeni nazw. Niestandardowe API sprawdza token JWT użytkownika i jego przypisanie do przestrzeni nazw, a następnie przez HTTPS zwraca dane połączenia i certyfikat przypisany do tej przestrzeni. AWS nie podało daty samej migracji. Opis architektury AWS
Tożsamość użytkownika potwierdza JWT, a certyfikat używany w połączeniu mTLS identyfikuje przestrzeń nazw. Certyfikat ma nazwę zgodną ze schematem <user-namespace>.eks.internal; AWS zwraca uwagę, by ta końcówka nie kolidowała z firmowym DNS. W przestrzeni nazw współdzielonej przez wiele osób certyfikat przypisany użytkownikowi pozwala dokładniej ustalić, kto się łączył: opisany certyfikat przestrzeni nazw sam nie zawiera identyfikatora użytkownika.
Dla ruchu WebRTC AWS wykorzystuje Amazon Kinesis Video Streams jako przekaźnik TURN. W tym wdrożeniu usługa zastąpiła samodzielnie utrzymywany STUNner, a wraz z nim opisany przez AWS mechanizm wymiany tokenów na dane dostępowe TURN. AWS pozostawiło domyślny serwer sygnalizacyjny Cuttlefish, ponieważ jego zastąpienie wymagałoby zmian w kodzie Cuttlefish i mogłoby zagrozić zgodności z projektem źródłowym.
Wymagania i odnawianie certyfikatów
Wzorzec Envoy zakłada izolację przestrzeni nazw, ograniczone uprawnienia RBAC oraz reguły NetworkPolicy z domyślną odmową ruchu. Bez tych reguł ruch może ominąć bramę. Projekt wymaga też walidacji JWT przez niestandardowe API oraz AWS Private CA, cert-managera i wtyczki wystawcy AWS Private CA dla cert-managera. AWS opisuje wymagane zabezpieczenia i konfigurację
Certyfikat ma ważność 12 godzin, a okno odnowienia wynosi 4 godziny. W opisanej konfiguracji cert-manager zwykle rozpoczyna odnawianie po upływie dwóch trzecich ważności, czyli po 8 godzinach. Envoy Gateway pobiera odnowione certyfikaty przez SDS, bez restartu poda.
W tym układzie mTLS kończy się na Envoy. Odcinek od bramy do poda nie jest szyfrowany przez mTLS; reguły NetworkPolicy ograniczają natomiast dostęp do portu ADB. AWS wskazuje certyfikaty na poziomie poda lub sidecary jako możliwości rozszerzenia ochrony na dalszy odcinek. W opisanej architekturze ścieżka ADB nie korzysta z AWS WAF, podczas gdy niestandardowe API REST działa za HTTPS i AWS WAF.
Envoy dla ADB czy NGINX Ingress dla HTTPS
Oba wzorce używają certyfikatów klienta, ale obsługują różne ścieżki ruchu. Przypadek Cuttlefish wykorzystuje Envoy jako przestrzenią nazw ograniczone proxy TCP dla ADB. Oddzielna instrukcja AWS pokazuje weryfikację certyfikatów klienta przez NGINX Ingress dla aplikacji dostępnej przez HTTPS.
| Wymiar | Envoy Gateway w przypadku Cuttlefish | NGINX Ingress w przykładzie AWS |
| Ruch | TCP/ADB do podów w przestrzeni nazw | HTTPS do aplikacji przez Ingress |
| Uwierzytelnianie klienta | mTLS na połączeniu z Envoy; API sprawdza JWT i przypisanie do przestrzeni nazw | Adnotacje Ingress włączają weryfikację certyfikatu klienta |
| Certyfikaty | AWS Private CA i cert-manager wystawiają krótkotrwałe certyfikaty przypisane do przestrzeni nazw | Sekret Kubernetes zawiera certyfikat serwera, klucz prywatny i certyfikat CA |
| Ważne ograniczenie | mTLS nie obejmuje odcinka Envoy–pod | Przykładowe certyfikaty samopodpisane są przeznaczone do testów |
Instrukcja AWS dla NGINX Ingress opisuje test, w którym żądanie bez certyfikatu klienta zwraca kod HTTP 400, a żądanie z certyfikatem dociera do aplikacji. AWS zaleca do produkcji AWS Private CA albo istniejące firmowe PKI zamiast samopodpisanych certyfikatów z przykładu. To wzorzec dla HTTPS Ingress, a nie zamiennik przestrzenią nazw ograniczonego proxy TCP używanego w przypadku ADB.
Jakie wyniki wydajności podaje AWS
W porównaniu z wcześniejszą ścieżką przez bastion AWS podaje, że instalacja aplikacji trwała 3–4 minuty, a każda podróż polecenia ADB tam i z powrotem zajmowała 1–2 sekundy. W ścieżce Envoy instalacja trwała poniżej 30 sekund, a wykonanie polecenia ADB poniżej 100 ms. Osobno AWS podaje opóźnienie bramy poniżej 50 ms w porównaniu z lokalną konfiguracją. Są to różne pomiary, a AWS opisuje wyniki własnego wdrożenia. Wyniki i architekturę przedstawia AWS
W przypadku WebRTC AWS informuje o stabilnych połączeniach przy szczytowym obciążeniu i braku potrzeby ręcznej aktualizacji tras po przeniesieniu podów między strefami dostępności. Koszty Amazon Kinesis Video Streams w tym układzie zależą od aktywnych kanałów sygnalizacyjnych, liczby wiadomości sygnalizacyjnych i czasu przesyłania przez TURN.
