2. 多租户隔离基础：租户模型、资源隔离策略及隔离失效的典型场景

多租户隔离是云原生平台安全性的基石。在 SOPS 策略评审中，评审人员必须理解租户模型如何定义权限边界，以及网络、存储、计算三大资源的隔离策略如何影响制品签名链路的可信性。隔离失效往往不是单一漏洞，而是策略配置与资源边界之间的错位。

2.1 租户模型：从单集群到分层隔离

租户模型定义了“谁可以访问什么资源”。在 Kubernetes 原生环境中，常见的租户模型分为以下三种：

2.2 资源隔离策略：网络、存储、计算

三大资源的隔离策略直接影响制品签名链路的完整性。以下分别阐述每种策略的配置要点与失效模式。

2.2.1 网络隔离

网络隔离防止未授权的租户流量进入签名服务或密钥存储端点。核心策略包括：

• NetworkPolicy：基于标签的入站/出站规则，限制签名 Pod 只接受来自 CI/CD 系统的流量。
• 服务网格 mTLS：在 Sidecar 层强制双向 TLS，确保签名请求来源身份可验证。
• API 网关策略：在入口处校验 JWT 或 SPIFFE 身份，拒绝无凭证的签名调用。

2.2.2 存储隔离

存储隔离保护签名密钥、制品摘要和策略文件不被跨租户篡改。关键策略：

• PV/PVC 访问模式：使用 ReadWriteOncePod 确保密钥卷只能被一个 Pod 挂载。
• 对象存储桶策略：为每个租户分配独立 Bucket，并附加 IAM 条件键限制 s3:PutObject 仅允许签名服务角色。
• 加密密钥分层：使用 KMS 自动密钥轮换，租户密钥加密后存储，防止存储层泄露。

2.2.3 计算隔离

计算隔离确保签名操作在独立的执行环境中运行，避免侧信道攻击或资源抢占导致签名服务降级。策略包括：

• Pod Security Standards (PSS)：强制 restricted 策略，禁止特权容器和 hostPath 挂载。
• RuntimeClass：为签名 Pod 指定 gVisor 或 Kata 容器，增加内核隔离层。
• 资源配额 (ResourceQuota)：限制每个租户的 CPU/内存，防止恶意租户通过资源耗尽影响签名可用性。

2.3 隔离失效的典型场景

以下 SVG 图展示了三种最常见的隔离失效路径，以及它们如何导致制品签名链路权限被突破。

2.4 隔离失效的检测与修复策略

在 SOPS 策略评审中，针对上述失效场景，建议采用以下检测与修复策略：

1. 网络隔离审计：使用 kubectl describe networkpolicy 检查签名命名空间的入站/出站规则，确保没有 0.0.0.0/0 的宽松规则。
2. 存储访问审计：扫描所有 PV 的 accessModes，标记非 ReadWriteOncePod 的密钥卷；检查对象存储桶策略是否包含 Principal: "*"。
3. 计算隔离审计：验证签名 Pod 的 securityContext 是否包含 runAsNonRoot: true 和 seccompProfile: RuntimeDefault。
4. 运行时验证：部署准入控制器（如 OPA/Gatekeeper），强制新创建的签名 Pod 必须满足隔离基线。