四层租户隔离防御跨租户风险，工程师强调可观测性是避免虚假安全感的关键

一句话结论

ReadyOn 在 EKS 上构建四层租户隔离架构阻断跨租户访问，工程师强调必须通过可观测性验证边界是否生效，否则等同于虚假安全感。

关键要点

• ReadyOn 的 Harmony 平台在 Amazon EKS 上采用命名空间、Karpenter 节点池、VPC 安全组和 Aurora 数据库四层隔离设计，限制跨租户访问。
• 第二层计算隔离要求 Pod 必须同时容忍标识租户和工作负载类型的双污点才能被调度，准入控制器验证容忍配置与租户相符。
• 第四层采用每租户独立的 Aurora 数据库集群隔离数据，而非共享数据库的行级过滤，并使用租户作用域的 AWS Secrets Manager 路径。
• 斯坦福大学商学院教授 Mohammad Akbarpour 指出，核心挑战是在推进 AI 能力的同时，让围绕不可访问数据和工作流设置的边界难以逾越。
• 工程师 Juan Pablo Gaviria 认为，若可观测性跟不上隔离深度，追踪数据就无法暴露不同控制措施之间的缺口，会导致虚假的安全感。

背景与事实

ReadyOn 推出了运行在 Amazon EKS 上的 Harmony 劳动力智能平台，该平台为企业客户处理薪资数据、组织层级和运营分析。由于处理敏感数据，ReadyOn 设计了一套四层租户隔离架构，从 Kubernetes、计算、网络和 Amazon VPC 四个层面构建相互重叠的防线。该设计将控制措施对应到一个包含 10 个阶段的多租户威胁模型，特别关注租户工作负载遭入侵后的横向移动风险。ReadyOn 表示，迄今为止的对抗性演练尚未发现成功的跨租户路径。

第一层隔离在 Kubernetes 层面，为每个租户使用专用的命名空间，并配置 RBAC、资源配额、准入控制和默认拒绝的网络策略。ReadyOn 使用 Argo CD ApplicationSets 根据基于 Git 的配置生成这些资源，为各租户提供相同的基线控制措施，并自动纠正未经授权的变更。第二层隔离计算资源，Karpenter 通过双污点策略为每个租户预置专用节点池。Pod 必须同时容忍用于标识租户的污点和用于标识工作负载类型的污点，才能被调度。准入控制器还会验证请求的容忍配置是否与命名空间所属租户相符。

第三层将控制措施延伸到 Kubernetes 之下。每租户独立的 VPC 安全组将数据库连接限制在对应租户的节点池，而 Kubernetes 网络策略则在命名空间之间实施默认拒绝。EKS API 端点设为私有，并通过 VPN、OpenID Connect 和多因素身份验证访问。第四层通过专用 Aurora 集群隔离租户数据，而不是依赖共享数据库中的行级过滤。ReadyOn 还使用限定租户作用域的 AWS Secrets Manager 路径、通过 IAM Roles for Service Accounts 获取的短期凭证，以及专用的可观测性后端。

影响分析

这对中文开发者与云架构从业者是一个明确的分析判断：单纯堆叠安全控制层而不建立验证机制，存在高估安全性的风险。亚马逊云科技文档指出，Kubernetes 命名空间、RBAC、配额和网络策略提供的是逻辑隔离，并不能阻止工作负载共享底层节点。Sparq 的 亚马逊云科技 首席工程师 William Antonio G 强调，对于单租户集群，加固是一个已有充分文档说明的挑战。但加入多租户后，威胁模型就发生了根本变化。中文团队在设计多租户云原生架构时，必须认识到隔离深度与可观测性深度必须匹配。如果无法追踪工作负载身份与数据库和网络层面控制措施的关联，就无法发现不同控制措施之间的缺口，这种“看不见”的边界比“不存在”的边界更危险。

适用边界

该结论不适用于单租户隔离场景，单租户集群的加固挑战已有充分文档说明，无需应用多租户威胁模型。该架构分析也主要基于 Amazon EKS 和 Aurora 的技术栈，对于使用其他云服务商或托管 Kubernetes 服务的团队，具体的污点策略、VPC 安全组配置和数据库隔离实现方式需重新评估。此外，四层隔离设计并未解决数据在应用层内存中的残留风险，若应用本身存在漏洞，仍需配合运行时安全监控。

孤本观察

基于本文事实的判断，ReadyOn 保留共享 EKS 环境但将租户边界扩展到调度、网络和专用数据基础设施的架构，实际上是将隔离责任从单一控制点分散到了多个重叠层。这种设计虽然增加了验证复杂度，但通过 Argo CD 自动纠正和准入控制验证，降低了人为配置漂移的风险，其核心编辑观察在于：可观测性不是隔离的附加功能，而是验证隔离是否真正生效的必要性前置条件。

来源：InfoQ 中文 AI