研究提出在多租户Kubernetes中弥补ADB与WebRTC协议安全缺口的架构

Android Debug Bridge（ADB）和 Web Real-Time Communication（WebRTC）等协议默认使用未加密通道进行网络通信，且不支持 JSON Web Tokens（JWT）等企业级身份验证机制。在多租户 Kubernetes 集群中——包括 Amazon Elastic Kubernetes Service（Amazon EKS）——除非配置网络策略限制跨命名空间流量，否则 pod 默认可以访问其他租户的开放端口。此外，逐个修改每个协议无法扩展。本文介绍一种基于三个可复用组件构建的架构：命名空间范围的 mutual TLS（mTLS）网关、通过 Amazon Kinesis Video Streams 提供的托管 TURN 中继，以及与企业身份提供商（IdP）绑定的 JWT 身份链。本文侧重于架构决策和经验教训，而非逐步部署指南。

本文假设已配置命名空间隔离的 EKS 集群、可签发 JWT 的企业 IdP，以及已在账户中设置的 AWS Private Certificate Authority（AWS Private CA）——一项用于签发私有证书的托管服务。cert-manager——一个自动化证书签发和续期的开源 Kubernetes 附加组件——和 AWS Private CA 签发者插件应已在集群中运行。该架构还假设具备部署 Envoy Gateway（一个基于 Envoy 代理构建的 Kubernetes API 网关）的权限。所使用的关键身份验证机制是 mTLS，即客户端和服务端都出示证书以相互验证。

在 Cuttlefish 部署中（Cuttlefish 是 Google 的可配置虚拟 Android 设备，运行在容器中），第一种方案将此流量通过堡垒主机路由到 Amazon EKS 控制平面，如图 1 所示。

图 1：旧架构（已被取代），仅用于对比。开发者工作站、堡垒主机和 Amazon EKS 控制平面之间的通信流程

图 1 展示了业界访问私有 Amazon EKS 集群的常见模式。我们分享此图是为了帮助其他人识别并迁移远离类似设计，以适用于低延迟环境。请勿实施此设计。当前架构将在本文后面描述和展示。

在现已弃用的架构中，自定义 API 通过对照企业 IdP 检查每个用户的身份并执行 pod 级授权来处理身份验证。该自定义 API 为命令行界面（CLI）提供支持，使您可以在分配的命名空间中列出 pod 并连接到您的设备。

JWT 身份链将每个用户映射到 AWS Security Token Service（AWS STS）RoleSessionName，因此审计日志中的每次 AWS API 调用都可追溯到具体个人，即使在多租户环境中也是如此。

这些凭证建立了一个两跳端口转发，从您的机器到堡垒主机，再从堡垒主机到目标 pod。由于所有流量都通过 Kubernetes API 服务器路由，即使集群本身保持私有，并发会话也会造成吞吐量瓶颈。

当通信双方位于 NAT 网关之后且无法建立直接点对点连接时，需要 TURN 服务器——一种媒体中继。

初始部署使用了 STUNner，这是一个为 WebRTC 媒体接入设计的开源 Kubernetes Session Traversal Utilities for NAT（STUN）和 Traversal Using Relays around NAT（TURN）网关。STUNner 带来了三个运维和安全挑战。

由于 STUNner 没有与 AWS 服务或企业 IdP 的原生集成，我们构建了一个自定义令牌交换服务，将 IdP 令牌转换为有时间限制、命名空间范围的 TURN 凭证。随着使用量增长，修补、监控和扩展 TURN 服务器成为反复出现的负担。可用区之间的 pod 迁移需要手动更新路由规则，而 STUNner 在高峰使用期间会断开 WebRTC 连接。

WebRTC 的信令服务器引入了单独的安全风险。WebRTC 使用 Datagram Transport Layer Security（DTLS）和 Secure Real-Time Transport Protocol（SRTP）加密媒体，但未为信令服务器定义身份验证或加密；您必须自行构建，这会使控制平面信令暴露在外。

该架构不使用 Kinesis Video Streams 信令通道，因为集成它需要对 Cuttlefish 源代码补丁进行大量更改。Cuttlefish 源代码已被修补以支持非 Google TURN 服务器，而进一步支持非 Google 信令服务器的更改使部署进一步偏离上游 Cuttlefish，存在兼容性问题风险。因此，该架构保留了默认的 Cuttlefish 信令服务器，并在应用层围绕它设计了基于 JWT 的会话验证和信令端点上的 TLS 终止。

该架构保留了命名空间隔离、基于 JWT 的身份验证、自定义授权 API 和 Cuttlefish 补丁；其中后三项是本部署特有的。除 Cuttlefish 补丁外，所有组件均可复用。

可复用组件包括用于 mTLS 认证 TCP 代理的命名空间范围 Envoy Gateway、通过 AWS Private CA 由 cert-manager 驱动的证书轮换，以及作为托管 TURN 提供商的 Kinesis Video Streams。

mTLS 网关假设其他若干控制措施已到位：

对于 ADB 连接，该架构使用 Envoy Gateway 进行 mTLS 身份验证。每个命名空间运行自己的 Envoy Gateway 实例，仅将流量路由到该命名空间内的 pod。在集群中运行并带有 AWS Private CA 签发者插件的 cert-manager 会在创建时为每个命名空间从 AWS Private CA 请求短期 mTLS 证书。在生产环境中，请在部署网关和签发证书之前应用 NetworkPolicies。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）