ReadyOn四层租户隔离跑EKS：边界生效吗？

ReadyOn 近日披露，其 Harmony 劳动力智能平台跑在 Amazon Elastic Kubernetes Service（EKS）上，租户隔离靠四层架构实现：Kubernetes 命名空间、专用 Karpenter 节点池、Amazon VPC 安全组，以及每租户一个独立 Amazon Aurora 数据库，分别从 Kubernetes、计算、网络和数据四个层面卡住跨租户访问。Harmony 给企业客户处理的是薪资数据、组织层级和运营分析。ReadyOn 把这些控制措施对到一个含 10 个阶段的多租户威胁模型上，最在意的是某个租户工作负载被攻破之后的横向移动。该公司称，到目前为止，对抗性演练没有发现能走通的跨租户路径。

斯坦福大学商学院教授 Mohammad Akbarpour 在 LinkedIn 上发帖谈 ReadyOn 的安全架构，他把更大的难题概括为：一边推进 AI 能力，一边要让围着不可访问数据和工作流设下的边界难以逾越。

Sparq 的亚马逊云科技首席工程师 William Antonio G 也在 LinkedIn 上讨论了这套架构，他指出多个租户共用基础设施时，安全模型已经变了。他的原话是：“对于单租户集群，加固是一个已有充分文档说明的挑战。但加入多租户后，威胁模型就发生了根本变化。”

第一层给每个租户单独划 Kubernetes 命名空间，配上 RBAC、资源配额、准入控制和默认拒绝的网络策略。这些资源由 ReadyOn 用 Argo CD ApplicationSets 按基于 Git 的配置生成，各租户拿到同一套基线控制，出现未经授权的改动会被自动纠正。

第二层管的是计算资源。Karpenter 用双污点策略为每个租户备好专用节点池，Pod 要同时容忍标识租户的污点和标识工作负载类型的污点才调得过去。准入控制器还会核对请求里的容忍配置跟命名空间所属租户对不对得上。

ReadyOn 的四道防线依次是命名空间、计算、网络和数据隔离，每一层各自堵住相应的跨租户路径。

第三层把控制措施伸到 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 一路扩到调度、亚马逊云科技网络和专用数据基础设施。在这套架构里，这些控制措施是相互重叠的防线，并不指望单独哪一层就能提供完整隔离。