租户隔离做了四层就够吗？工程师提醒还需可观测性验证边界是否生效

ReadyOn介绍了其运行在Amazon EKS上的Harmony劳动力智能平台所采用的四层租户隔离架构。该设计结合Kubernetes命名空间、专用Karpenter节点池、Amazon VPC安全组和每租户独立的Amazon Aurora数据库，从Kubernetes、计算、网络和数据四个层面限制跨租户访问。Harmony为企业客户处理薪资数据、组织层级和运营分析，ReadyOn将其控制措施对应到一个包含10个阶段的多租户威胁模型，尤其关注租户工作负载遭入侵后的横向移动。该公司表示，迄今为止对抗性演练尚未发现成功的跨租户路径。

第二层隔离计算资源。Karpenter通过双污点策略为每个租户预置专用节点池，Pod必须同时容忍用于标识租户的污点和用于标识工作负载类型的污点才能被调度，准入控制器还会验证请求的容忍配置是否与命名空间所属租户相符。第三层将控制措施延伸到Kubernetes之下：每租户独立的VPC安全组将数据库连接限制在对应租户的节点池，Kubernetes网络策略在命名空间之间实施默认拒绝，EKS API端点设为私有，并通过VPN、OpenID Connect和多因素身份验证访问。

第四层通过专用Aurora集群隔离租户数据，而不是依赖共享数据库中的行级过滤。ReadyOn还使用限定租户作用域的AWS Secrets Manager路径、通过IAM Roles for Service Accounts获取的短期凭证，以及专用的可观测性后端。亚马逊云科技文档指出，Kubernetes命名空间、RBAC、配额和网络策略提供的是逻辑隔离，并不能阻止工作负载共享底层节点。

这一分层模型也引发讨论：如果没有相应的可观测性，能否有效验证隔离控制措施。在LinkedIn上评论该架构的工程师Juan Pablo Gaviria认为，追踪数据需要将工作负载身份与数据库和网络层面的控制措施关联起来，才能暴露不同控制措施之间的缺口，“隔离做得再深，如果可观测性跟不上，就与虚假的安全感无异”。ReadyOn保留了共享的EKS环境，同时将租户边界从Kubernetes扩展到调度、网络和专用数据基础设施，将这些控制措施视为相互重叠的防线，而非假设任何单独一层都能提供完整隔离。