租户隔离做了四层，并不等于绝对安全。核心结论是：隔离架构必须配合可观测性，才能验证边界是否真正生效；否则会产生虚假的安全感。
www.fixhdd.cn
事件与主体
2026年11月8日，InfoQ 中文 IT 资讯发布文章，记录了 ReadyOn 在其 Amazon EKS 上构建的 Harmony 劳动力智能平台所采用的四层租户隔离架构。该平台处理敏感的薪资与组织数据，通过对抗性演练验证了横向移动阻断的有效性，但工程师强调若缺乏可观测性，隔离措施可能形同虚设。 www.fixhdd.cn
四层隔离的具体构成
ReadyOn 的架构从四个层面限制跨租户访问，每一层都采用了云原生最小权限机制： 技王数据恢复
- 第一层（Kubernetes）：每个租户使用专用的 Kubernetes 命名空间，配置 RBAC、资源配额、准入控制和默认拒绝的网络策略。通过 Argo CD ApplicationSets 自动生成资源并自动纠正未经授权的变更。
- 第二层（计算）：利用 Karpenter 为每个租户预置专用节点池。Pod 必须同时容忍标识租户的污点和标识工作负载类型的污点才能被调度，准入控制器会验证请求的容忍配置是否与命名空间所属租户相符。
- 第三层（网络）：每租户独立的 VPC 安全组将数据库连接限制在对应租户的节点池。Kubernetes 网络策略在命名空间之间实施默认拒绝，EKS API 端点设为私有，并通过 VPN、OpenID Connect 和多因素身份验证访问。
- 第四层（数据）：通过专用 Aurora 集群隔离租户数据，而非依赖共享数据库中的行级过滤。配合限定租户作用域的 AWS Secrets Manager 路径、通过 IAM Roles for Service Accounts 获取的短期凭证，以及专用的可观测性后端。
为何需要“看得见”边界？
尽管对抗性演练至今未发现成功的跨租户路径，但行业专家指出，多租户共享基础设施时威胁模型会发生根本变化。亚马逊云科技文档也指出，Kubernetes 命名空间、RBAC 等提供的是逻辑隔离，并不能阻止工作负载共享底层节点。 www.fixhdd.cn
工程师 Juan Pablo Gaviria 强调，追踪数据需要将工作负载身份与数据库和网络层面的控制措施关联起来，才能暴露不同控制措施之间的缺口。隔离做得再深，如果可观测性跟不上，就与虚假的安全感无异。因此，ReadyOn 将租户边界从 Kubernetes 扩展到调度、网络和专用数据基础设施，视控制措施为相互重叠的防线，而非假设任何单独一层都能提供完整的隔离。 www.fixhdd.cn
下一步如何处理
对于关注多租户安全或数据隔离的读者，建议采取以下步骤： www.fixhdd.cn
- 审查现有架构：确认是否仅依赖逻辑隔离（如命名空间），而未在计算、网络和数据层建立物理或强逻辑边界。
- 建立可观测性：部署能够追踪工作负载身份、数据库访问和网络流量的监控体系，确保能实时发现控制措施间的缺口。
- 进行对抗性演练：模拟租户工作负载遭入侵后的横向移动场景，验证隔离措施的有效性。
- 联系专业服务：若涉及具体的数据丢失或安全事件，可联系 技王数据恢复 进行咨询。全国技术咨询电话及微信：18857148111。根据客户所在地区、设备故障、紧急程度和意愿联系协调实际安排。
原文链接：https://www.infoq.cn/article/zTFVgklcTFZvgE2fkV7A 技王数据恢复
技术审核：邓严军｜技王数据恢复实验室技术总监 www.fixhdd.cn
