Kubernetes network policies restrict which pods can talk to each other, but they do nothing to encrypt traffic or enforce authentication for protocols like Android Debug Bridge and WebRTC that ship with insecure defaults. In multi-tenant Amazon EKS clusters, this leaves a gap where a compromised pod can sniff or inject into unencrypted streams even when network policies are applied.
The protocol problem hiding inside the cluster
Protocols such as ADB and WebRTC were designed for trusted local environments, not shared Kubernetes clusters. ADB typically runs over cleartext TCP on port 5555 with no built-in authentication, while WebRTC's data channels can operate over unencrypted UDP unless DTLS is explicitly enforced. When these workloads land in a multi-tenant EKS cluster, their traffic traverses the same CNI-managed network fabric as every other tenant.
A network policy that allows traffic from a frontend pod to a backend pod carrying ADB or WebRTC will happily pass the plaintext bytes. The policy matches IP, port, and namespace labels — it has no visibility into the payload. An attacker who gains a foothold in any pod allowed by that policy can intercept debug sessions, inject commands, or harvest media streams without triggering a single network policy violation.
The AWS Security Blog post highlights that these protocols also lack enterprise-grade identity integration. They don't speak JWT, mTLS, or OIDC natively. Retrofitting authentication means either wrapping the protocol in a sidecar proxy that terminates TLS and validates tokens, or replacing the protocol entirely with a secured alternative. Neither is a flip-the-switch change.
Where network policies still earn their keep
Network policies remain the first line of defense because they shrink the blast radius. A default-deny ingress policy on every namespace forces explicit allow rules, so a rogue pod in Tenant A cannot even attempt a connection to Tenant B's ADB port unless a policy explicitly permits it. This is table stakes for any multi-tenant EKS cluster and should be automated via policy-as-code tooling.
Calico, Cilium, and the AWS VPC CNI's native NetworkPolicy enforcement all operate at layer 3/4. They can't inspect WebRTC's DTLS handshake or verify that an ADB connection presents a valid certificate. But they can ensure that only the designated signaling service reaches the media server, and only the approved debugger pod reaches the ADB port. That reduces the attack surface from "any pod in the cluster" to "only the intended consumer."
Pair network policies with CNI-level flow logs or Hubble metrics to detect policy violations and anomalous connection patterns. A sudden spike in connections to port 5555 from an unexpected namespace is a concrete signal that something slipped through the policy net or that a legitimate workload is misbehaving.
Closing the encryption and identity gap
For ADB, the practical path is to run the daemon behind a mutual TLS tunnel such as stunnel or a service mesh sidecar like Envoy. The sidecar terminates mTLS, validates the client certificate against a SPIFFE identity, and forwards plaintext to localhost:5555. This keeps the existing ADB tooling unchanged while adding encryption and strong identity at the network edge.
WebRTC workloads should enforce DTLS-SRTP for media and DTLS for data channels — no exceptions. In Kubernetes, this means configuring the media server (Janus, MediaMTX, or a custom stack) to reject non-DTLS connections and integrating with a certificate manager like cert-manager to rotate short-lived certificates. The signaling plane must also require authenticated WebSocket connections backed by OIDC tokens validated at the ingress controller.
Adopt a defense-in-depth checklist: default-deny network policies per namespace, protocol-specific encryption enforced at the application or sidecar layer, identity-aware proxies for any legacy protocol that can't be upgraded, and continuous verification via flow logs and runtime security tools like Falco or Tetragon. The network policy is the fence; encryption and authentication are the locks on the gate.
What to do next
Audit every workload that exposes ADB, WebRTC, or similar cleartext protocols in your EKS clusters. Apply default-deny network policies today, then layer mTLS sidecars or DTLS enforcement for each protocol. Automate certificate rotation and validate the full stack with runtime threat detection.
Source: Addressing protocol security gaps in multi-tenant Kubernetes (AWS).
