ReadyOn在Amazon EKS上的多租户隔离“四墙”架构
内容提要
ReadyOn在Amazon EKS上为多租户平台构建“四墙”隔离架构：命名空间隔离、Karpenter专用节点池、VPC安全组与网络策略、每租户独立Aurora数据库。四层防御叠加，跨租户需突破全部屏障。结合GitOps、IRSA短期凭证与容器加固，实现零信任租户隔离。
延伸解读
命名空间隔离的局限与补充
文章明确指出，Kubernetes 命名空间并非设计为安全边界，仅依赖它进行多租户隔离存在风险。ReadyOn 将命名空间作为逻辑基础，但通过 GitOps 强制一致性、RBAC 和准入控制来强化。然而，命名空间仍共享控制平面，因此需要计算、网络和数据层的额外隔离来弥补其不足。
Karpenter 双污点策略的调度保障
计算隔离层使用 Karpenter 为每个租户提供专用节点池，并采用双污点策略：节点同时带有租户标识和工作负载类型污点，Pod 必须容忍两者才能调度。此外，准入控制器验证容忍度与命名空间租户身份匹配，防止伪造容忍度导致的跨租户调度。这确保了租户工作负载在物理计算资源上的隔离。
网络与数据层的纵深防御
网络隔离在 VPC 层实现，每租户 Aurora 集群的安全组仅允许该租户节点访问，Kubernetes 网络策略默认拒绝跨命名空间流量。数据隔离则为每租户提供独立 Aurora 集群和 KMS 密钥，避免共享数据库的查询逻辑风险。IRSA 提供短期凭证，消除长期密钥。这些层共同确保即使其他层被突破，数据仍受保护。
分层防御的协同与验证
四墙模型强调防御纵深：攻击者必须同时突破所有层才能跨租户。ReadyOn 通过对抗性演练模拟租户 Pod 尝试所有跨租户路径，至今未发现成功案例。这种分层方法提高了攻击成本，但文章也承认各层共享部分控制平面，因此视为纵深防御而非完全独立。
Q&A
ReadyOn在Amazon EKS上如何实现多租户隔离？
ReadyOn采用“四墙”架构：第一墙是命名空间隔离，通过Argo CD ApplicationSet为每个租户生成独立的命名空间、RBAC、资源配额和准入控制；第二墙是计算隔离，使用Karpenter为每个租户创建专用节点池，并采用双重污点策略；第三墙是网络隔离，通过VPC安全组和Kubernetes网络策略实现默认拒绝；第四墙是数据隔离，每个租户拥有独立的Aurora数据库集群和租户范围的密钥。四层防御叠加，跨租户需同时突破所有屏障。
为什么仅靠Kubernetes命名空间不足以实现多租户安全隔离？
Kubernetes命名空间并非设计为安全边界。默认情况下，Kubernetes允许匿名请求到达API服务器，Pod默认以root运行，网络策略需要手动编写。命名空间隔离仅提供逻辑边界，无法阻止跨租户的节点调度、网络通信或数据访问。因此ReadyOn在命名空间之上增加了计算、网络和数据层的额外隔离。
ReadyOn如何利用Karpenter实现计算层的租户隔离？
ReadyOn使用Karpenter为每个租户配置专用节点池，并采用双重污点策略：每个节点带有租户标识污点（如tenant=acme-corp）和工作负载类型污点（如workload=frontend）。Pod必须同时容忍这两个污点才能被调度。此外，准入控制器会验证容忍度是否与命名空间的租户身份匹配，防止伪造容忍度导致的跨租户调度。节点IAM角色也限定为单个租户的资源。
ReadyOn在数据层如何确保租户数据隔离？
ReadyOn为每个租户提供专用的Amazon Aurora数据库集群，而非共享数据库。每个集群使用独立的AWS KMS密钥加密，租户工作负载通过IRSA获取短期凭证访问自己的数据库。没有共享数据库，因此不存在因遗漏WHERE子句导致的数据泄露风险。此外，每个租户有独立的可观测性后端，监控数据也相互隔离。
ReadyOn如何通过GitOps确保所有租户的安全配置一致？
ReadyOn使用Argo CD ApplicationSet管理租户命名空间。当新租户加入时，只需在Git配置清单中添加一个条目，自动化便会生成命名空间、网络策略、RBAC绑定、资源配额和密钥配置。GitOps控制器持续将集群实际状态与Git中声明的状态进行协调，任何手动修改都会在几秒内被自动还原。这确保了所有租户获得完全相同的安全配置，没有遗留的弱策略。
ReadyOn的四墙架构如何防御横向移动攻击？
ReadyOn将防御映射到10阶段威胁模型，其中第8阶段为横向移动。在该阶段，攻击者从租户A的Pod尝试跨越边界到租户B。四墙同时生效：创建跨命名空间路由被墙1阻止；在租户B节点上调度Pod被墙2阻止；打开数据库连接和跨命名空间通信被墙3阻止；获取密钥和查询监控数据被墙4阻止。所有六种跨租户路径均被阻断，没有箭头能到达租户B。
ReadyOn如何管理工作负载的凭证以避免长期密钥？
ReadyOn使用IAM Roles for Service Accounts (IRSA)，通过EKS集群与IAM之间的OIDC联邦，为每个租户的工作负载颁发短期AWS STS凭证。凭证在几分钟内过期，应用程序不持有长期访问密钥。此外，节点强制执行IMDSv2并限制跳数，防止Pod访问实例元数据端点。
ReadyOn的四墙架构带来了哪些主要好处？
主要好处包括：防御10个威胁模型阶段，所有六种跨租户路径在横向移动阶段被阻断；应用程序工作负载无长期凭证，全部使用短期OIDC联邦令牌；通过GitOps模板实现所有租户一致的安全配置，无遗留例外；自愈漂移校正可在几秒内还原未授权更改；多区域主动-被动架构，通过Amazon Route 53实现自动故障转移。
