Earlier deployments routed insecure protocols such as ADB and WebRTC through a bastion host and a bespoke API that performed per‑user JWT checks before reaching pods. The new design swaps that pattern for three reusable components: namespace‑scoped mutual TLS (mTLS) gateways, a managed TURN relay via Amazon Kinesis Video Streams, and JWT identity chains linked to an enterprise IdP. Practitioners gain a scalable, policy‑driven way to protect otherwise unencrypted traffic inside a shared Amazon EKS cluster.
Why the Change Matters
In a multi‑tenant EKS environment, pods can reach any open port in another namespace unless network policies are explicitly applied. Protocols like ADB, WebRTC, and VNC transmit data without encryption and lack built‑in enterprise authentication, leaving tenant workloads vulnerable to accidental or malicious cross‑namespace access. By enforcing mTLS at the namespace level, both client and server present certificates issued by a private CA, guaranteeing mutual authentication before any payload is exchanged.
Core Components of the New Architecture
- Namespace‑scoped mTLS gateways: Deployed with
Envoy Gatewayper namespace, these proxies terminate TLS using certificates provisioned bycert-managerand theAWS Private CA issuer plugin. The gateways enforce mutual authentication and forward traffic only after successful certificate validation. - Managed TURN relay: WebRTC media streams are routed through Amazon Kinesis Video Streams, providing a reliable TURN service without requiring each tenant to manage its own relay infrastructure.
- JWT identity chain: An enterprise IdP issues JWTs that are validated by the gateway before certificate issuance. This ties user identity to the mTLS certificate lifecycle, ensuring that only authorized principals can obtain a client certificate for a given namespace.
Implementation Considerations
Deploying this pattern assumes the following prerequisites are already in place: an EKS cluster with namespace isolation, an IdP capable of issuing JWTs, AWS Private CA for private certificate authority, cert-manager with the AWS Private CA issuer plugin, and permission to install Envoy Gateway. The workflow typically follows these steps:
- Developer obtains a JWT from the corporate IdP.
- The JWT is presented to a gateway endpoint that triggers
cert-managerto request a short‑lived client certificate from the private CA. - The client uses the certificate to establish an mTLS session with the namespace‑scoped Envoy proxy.
- Media traffic that requires NAT traversal is automatically forwarded to the Kinesis Video Streams TURN relay.
Because certificate issuance is automated, operators must monitor the health of cert-manager and the private CA, and ensure that revocation lists are propagated to all Envoy instances. Network policies should still be applied to restrict pod‑to‑pod communication beyond the mTLS layer, as the gateway only secures inbound traffic to the namespace.
Operational and Security Implications
Adopting namespace‑scoped mTLS centralizes authentication, reducing the need for per‑protocol patches or custom proxies. It also creates a clear audit trail: each client certificate maps back to a JWT, which in turn maps to an IdP user. However, the model introduces new operational responsibilities, such as managing certificate rotation schedules and ensuring that the Envoy configuration stays in sync with namespace changes. The reliance on a managed TURN service offloads media relay complexity but adds a dependency on Amazon Kinesis Video Streams availability.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Engineers should evaluate existing unencrypted protocol flows for cross‑tenant exposure and consider migrating to the namespace‑scoped mTLS gateway pattern. Key actions include provisioning cert-manager with the AWS Private CA issuer, configuring Envoy Gateway per namespace, and integrating JWT validation with the corporate IdP. Monitoring certificate health and maintaining complementary network policies will be essential to preserve both security and reliability in a multi‑tenant EKS deployment.
