Multi-tenant Kubernetes’te ADB ve WebRTC trafiğini mTLS ile korumak

Amazon EKS üzerinde kurulan bir mimari, multi-tenant Kubernetes cluster’larında ADB (Android Debug Bridge) ve WebRTC gibi şifresiz, kurumsal authentication desteği olmayan protokolleri üç parçayla koruyor: namespace başına mTLS (mutual TLS) gateway’leri, Amazon Kinesis Video Streams üzerinden managed TURN relay ve kurumsal IdP (Identity Provider) ile bağlı JWT kimlik zinciri. Örnek ortam, container içinde çalışan sanal Android cihazı Cuttlefish’i işletiyor. Eski bastion host tasarımı ve self-managed STUNner bu mimariyle değiştirildi.

Envoy Gateway nedir?

Envoy Gateway, Envoy proxy’yi data plane olarak kullanan açık kaynak bir Kubernetes gateway projesidir. Kubernetes Gateway API kaynaklarını okuyup Envoy yapılandırmasına çevirir ve cluster’a giren trafiği yönetir. Ingress, TCP proxy ve mTLS gibi senaryolarda kullanılır. Alternatifleri arasında diğer Gateway API uygulamaları, örneğin Istio ve NGINX tabanlı controller’lar bulunur.

Kısaca Cuttlefish nedir

Cuttlefish, Google’ın geliştirdiği yapılandırılabilir sanal Android cihazıdır. Linux host’larda ve container içinde çalışır, Android platform geliştirme ve otomatik test için gerçek cihaz yerine kullanılır. Uzak erişim için ADB ve WebRTC tabanlı ekran akışı kullanır. Bilinen alternatifi Android Emulator’dür.

Bastion ve port-forward neden bırakıldı

Eski tasarımda trafik geliştirici makinesinden bastion host’a, oradan hedef pod’a iki adımlı port-forward ile gidiyordu. Her oturum Kubernetes API server’dan geçtiği için eşzamanlı bağlantılar throughput darboğazı yarattı. Cluster private kaldı, fakat API server veri yoluna dönüştü.

Bu desen için yazıdaki not net: “Do not implement this design.” Private EKS cluster’ınıza erişimi bastion ve kubectl port-forward ile kuruyorsanız, kullanıcı sayısı arttıkça aynı darboğaza girersiniz. Yeni mimari, multi-tenant Kubernetes ortamında veri trafiğini control plane’den alıp namespace başına çalışan Envoy Gateway’e taşıyor.

Sıra önemli: önce NetworkPolicy

Multi-tenant Kubernetes’te pod’lar varsayılan olarak diğer tenant’ların açık portlarına ulaşabiliyor. MTLS gateway bu yolu kendi başına kapatmıyor. Default-deny ingress politikası yoksa trafik gateway’i atlayıp doğrudan pod’a gidebilir; bu yüzden sıra önce NetworkPolicy, sonra gateway ve sertifika.

Hangi namespace’lerde politika olduğunu ve cert-manager sertifikalarının durumunu şöyle görebilirsiniz:

kubectl get networkpolicy -A
kubectl get certificate -A

CNI eklentiniz politikaları uygulamıyorsa NetworkPolicy nesneleri kâğıt üzerinde kalır. Listede politikası görünmeyen tenant namespace’lerinde gateway kurulsa bile pod’a doğrudan erişim açık kalır.

12 saatlik sertifika ve multi-tenant Kubernetes’te kimlik

Cert-manager her namespace için AWS Private CA’dan 12 saat ömürlü sertifika istiyor. Varsayılan yenileme ömrün üçte ikisinde başladığı için 8. Saatte devreye giriyor ve sertifika bitmeden 4 saatlik deneme payı kalıyor. CRL veya OCSP altyapısı kurmadan, sızan bir sertifikanın etkisi birkaç saatle sınırlanıyor. Envoy yenilenen sertifikayı SDS (Secret Discovery Service) üzerinden pod restart olmadan alıyor.

Başka ortamlara taşınabilecek kararlar:

• CommonName <user-namespace>.eks.internal biçiminde. Envoy handshake sırasında sertifikayı beklenen namespace’le eşleştiriyor. Son eki kurumunuzun DNS’iyle çakışmayacak şekilde seçin.
• Usages alanında client ve server authentication birlikte yer alıyor; aynı sertifika iki yönde de kimlik kanıtlıyor.
• Her namespace’e ayrı issuer kurmak yerine tek bir AWSPCAClusterIssuer tüm tenant’lara sertifika veriyor.

Kimlik iki katmanlı kuruluyor. JWT kimin bağlandığını, mTLS sertifikası bağlantının hangi namespace’e ait olduğunu kanıtlıyor. JWT zinciri her kullanıcıyı bir AWS STS RoleSessionName’e eşlediği için audit log’daki her AWS API çağrısı tek bir kişiye iniyor.

Bilinçli olarak açık bırakılan noktalar

Mimari bazı yolları korumasız bırakıyor. Kendi risk değerlendirmenize bunları ekleyin:

• Envoy ile pod arasındaki hop mTLS ile şifrelenmiyor, erişimi yalnızca NetworkPolicy sınırlıyor. Uyumluluk gereksiniminiz varsa sidecar proxy veya pod düzeyinde sertifikayla mTLS’i pod’a kadar uzatın.
• AWS WAF yalnızca REST API’nin önünde duruyor. ADB veri yolunda WAF yok; koruma mTLS, NetworkPolicy ve namespace izolasyonuna kalıyor.
• Sertifikanın subject alanında kullanıcı bilgisi yok. Model, namespace ile kullanıcının bire bir eşleştiği durumda işliyor. Paylaşımlı namespace’lerde veya ayrıntılı kayıt isteyen denetime tabi ortamlarda kullanıcı başına sertifika verin.
• WebRTC medyayı DTLS ve SRTP ile şifreliyor, signaling server için ise authentication tanımlamıyor. Örnekte Kinesis Video Streams’in signaling kanalı kullanılmamış; Cuttlefish’in varsayılan signaling server’ı korunmuş, JWT doğrulaması ve TLS sonlandırması uygulama katmanında kurulmuş.

STUNner yerine managed TURN

Self-managed STUNner için IdP token’larını namespace’e bağlı, süreli TURN kimlik bilgilerine çeviren bir servisi ayrıca yazmamız gerekmişti. Availability Zone’lar arası pod taşımaları routing kurallarında elle güncelleme istiyordu. Yoğun saatlerde WebRTC bağlantıları düşüyordu. Kinesis Video Streams IAM ile entegre olduğu için token-exchange servisi tamamen kalktı.

Karşılığında maliyet modeli değişiyor: aktif signaling kanalı, signaling mesajı ve TURN streaming dakikası başına ücret ödüyorsunuz. Boşta duran namespace TURN ücreti üretmiyor. Geçişten önce Kinesis Video Streams WebRTC servis kotalarını kontrol edin ve günlük oturum dakikanızı fiyat tablosuyla çarpıp self-managed TURN’ün işletim yüküyle karşılaştırın.