01 · 多租户隔离分级模型
Kubernetes命名空间提供的是逻辑隔离而非安全边界。明确这一事实后，多租户方案应按"租户间信任程度"分级选型——这是本课题KQ-3的直接回答。
| 级别 | 机制组合 | 能抵御什么 | 不能抵御什么 |
|---|---|---|---|
| L1 命名空间软隔离 | Namespace + ResourceQuota/LimitRange + PSA（Baseline/Restricted）+ NetworkPolicy默认拒绝 + RBAC收敛 | 粗心的资源滥用、无意的跨团队访问、低能力攻击者的 opportunistic 探测 | 恶意租户：共享内核逃逸（第4页）、DoS型资源竞争（quota只限总量不限瞬时）、通过API Server的集群级信息侧信道 |
| L2 节点池隔离 | L1 + 租户专用节点池（taints/tolerations）+ 节点级加固 | 多数逃逸的横向波及（逃逸只达节点，不直接达其他租户Pod） | 同池内合租风险仍在；控制面仍为共享 |
| L3 虚拟集群 | vCluster（Loft开源）等：每租户一个虚拟控制面（/apiserver/etcd独立），共享底层工作节点 | 控制面层面的配置错误与RBAC污染不再跨租户；租户获得"准集群管理员"体验 | 共享节点内核；虚拟控制面的宿主机攻击面 |
| L4 独立集群 | 每租户/每强合规域独立集群（Cluster API统一纳管） | 最高隔离：控制面、节点、网络、密钥全部分离；合规责任清晰 | 成本与运维复杂度最高；跨集群治理需平台化能力 |
选型决策链：①同组织同信任域的团队共享集群（L1+严格基线）；②面向外部开发者/客户的多租户平台至少L3（vCluster）；③金融/政务等强合规或"不可信代码执行"（如CI运行客户代码）场景直接评估L4，或L2叠加gVisor/Kata沙箱（第4页）作为性价比替代。
02 · 强隔离方案要点
2.1 虚拟集群（vCluster）
- 架构：每租户命名空间内运行虚拟控制面（精简apiserver+轻量存储如kine→SQLite，或外挂etcd），经Syncer将虚拟资源同步到宿主集群。
- 安全价值：租户在自己的虚拟集群里是"管理员"，其错误配置（过宽RBAC、危险PSP例外）不影响其他租户；宿主集群的强基线（PSS enforce、网络策略）仍兜底。
- 注意：宿主持久化与网络仍共享——网络策略在宿主层强制；vCluster自身的升级与漏洞跟随宿主集群治理。
2.2 微虚机兜底（沙箱运行时复用）
对"必须与其他租户共享节点"的不可信负载，第4页的gVisor/Kata是L2隔离的关键增强：逃逸只到微虚机边界而非宿主内核。三者组合（虚拟集群控制面隔离+沙箱节点隔离+宿主网络策略）可在不 proliferate 物理集群的前提下达到接近L4的租户防护水位。
03 · 控制面运维安全
运维能力本身就是安全能力——备份不可用、证书过期未换、升级窗口失控，都会把"可用性事件"演变为"安全事件"。
| 能力 | 基线要求 | 工具/命令（示例） |
|---|---|---|
| etcd备份与恢复 | 每日自动快照；异地加密存储；每季度恢复演练 | etcdctl snapshot save / snapshot restore；快照含全部Secret，存储安全等级=生产数据 |
| 证书轮换 | kubeadm集群年度轮换apiserver/etcd/front-proxy证书；监控剩余有效期（阈值30天告警） | kubeadm certs check-expiration / renew；外部CA对接则按CA流程 |
| 版本升级 | 官方对最近三个次要版本提供补丁支持（支持窗口约14个月），须保持持续升级节奏；控制面升级必须逐次跨小版本进行、不可跳级（旧版本先行验证后滚动升级） | 控制面先行、工作节点滚动；升级前etcd快照是法定动作 |
| 高可用 | 控制面至少3节点奇数成员（etcd仲裁）；跨可用区部署 | 堆叠式（kubeadm stacked）或外部etcd拓扑，权衡故障域 |
| 配置与密钥的GitOps管理 | 集群清单、策略、RBAC全部Git化+评审+漂移告警 | Argo CD/Flux；漂移检测（live vs desired）纳入日巡检 |
取证留证：①etcd快照同时也是取证来源（还原历史状态），但其敏感性要求访问双人双锁；②API审计日志（第3页）留存不少于180天（对标《网络安全法》第21条网络日志留存要求）；③节点级日志（kubelet、运行时）经DaemonSet采集，与容器生命周期解耦（容器删除后日志仍可查）。
04 · 威胁检测场景库
检测能力的可信度来自"场景—数据源—规则—验证"的可核查链条。以下场景库将第2页攻击路径与第3—5页数据源（API审计、运行时遥测、网络流量、DNS）逐一映射，供检测工程落地与红队验证共用。
| 检测场景 | 数据源 | 检测思路 | 验证方式（授权演练） |
|---|---|---|---|
| 匿名/异常API访问尝试 | API审计日志 | user=system:anonymous的写操作；非运维网段list secrets | 授权下以匿名请求探测，验证审计留痕与告警 |
| RBAC异常提升 | API审计 | 创建ClusterRoleBinding、授予escalate/bind/impersonate verb的突发行为 | 演练角色提权操作，核对告警时延 |
| ServiceAccount凭证滥用 | 审计+运行时 | SA token在异常位置使用（非Pod源IP调用API）；token批量访问不相关资源 | 用真实SA token从Pod外重放，验证检测 |
| 容器逃逸痕迹 | 运行时遥测（Falco/Tetragon） | mount到宿主路径、setuid执行、/proc/sys写、异常syscall序列 | 对照第4页谱系，在隔离节点演练 |
| 反弹Shell与C2 | 运行时+网络+DNS | 容器内shell+对外连接组合；周期性心跳域名；DNS TXT大载荷 | 用测试C2域验证全链路检出 |
| 挖矿与资源滥用 | 运行时+指标 | 进程特征（xmrig等）、矿池域名/IP连接、CPU突增背离基线 | 部署无害模拟挖矿进程，验证告警 |
| 恶意镜像部署尝试 | 准入Webhook日志 | 验签拒绝事件、非白名单registry、latest标签使用趋势 | 推送未签名测试镜像，验证拒绝与留痕 |
| 持久化驻留 | 审计+GitOps漂移 | 新增可疑CronJob、DaemonSet、突变Webhook、影子SA/RoleBinding；live状态偏离Git | 演练植入后门清单，核对漂移检测 |
检测工程度量：每个场景须记录"检出率/误报率/MTTD"三指标并纳入月度评审；规则变更Git化；与第8页成熟度模型挂钩——没有红队授权验证的检测规则不计入"已覆盖"。
05 · 事件响应流程
容器环境的事件响应有其特殊性：基础设施即代码使"重建"廉价，但Pod的短暂性也让证据易失。响应流程必须兼顾"快速遏制"与"证据保全"。
- 隔离动作速查：cordon（停止调度）+ drain（驱逐工作负载）是最快的节点级遏制；网络策略紧急对象（"deny-all + 仅放行SIEM"）应预置模板；镜像层面以准入策略封锁digest。
- 凭证轮换的范围纪律：Pod可能访问过的全部凭证都应视为泄露——包括ServiceAccount令牌（重建SA即轮换）、镜像仓库凭证、云IAM角色（IRSA映射）、以及应用层的全部外部账号。
- 不要做的：勿在证据固定前重启节点或删除etcd历史；勿以"删Pod"代替根除（持久化对象仍在）；勿在未定级前广而告之造成攻击者加速破坏。
本节参考来源（第7页）
NSA & CISA《Kubernetes Hardening Guidance》v1.1（2022）：日志与监控、事件响应与取证建议章节。
Kubernetes官方文档——etcd备份与恢复（kubernetes.io（etcd管理））、证书管理（kubernetes.io（kubeadm certs））、审计（第3页已引）。
vCluster官方文档：vcluster.com/docs；Cluster API：cluster-api.sigs.k8s.io；Argo CD：argo-cd.readthedocs.io；Flux：fluxcd.io。
Falco规则文档：falco.org/docs/rules；Tetragon TracingPolicy：tetragon.io（TracingPolicy）；MITRE ATT&CK for Containers（响应场景对照）：attack.mitre.org（Containers矩阵）。
《中华人民共和国网络安全法》第21条（网络日志留存不少于六个月）：《网络安全法》官方文本（2017年6月1日施行）。