3. 租户隔离需求分析：多租户场景定义、隔离边界与安全威胁模型

在构建基于 eBPF 的控制平面之前，必须首先明确“多租户”在系统内核层面的具体含义。不同于传统虚拟化中由 Hypervisor 提供的硬件级隔离，eBPF 场景下的租户隔离发生在内核共享资源之上，其需求分析直接决定了控制平面的分层粒度与通信协议设计。

3.1 多租户场景定义

本课程定义三类典型的多租户部署场景，每一类对 eBPF 程序的加载、执行与观测权限有截然不同的要求：

3.2 隔离边界三维模型

租户隔离需求可分解为三个正交的资源维度：网络、内存与文件系统。每个维度在 eBPF 上下文中都有独特的攻击面与防护手段。

3.2.1 网络隔离边界

• 数据平面隔离： 确保租户 A 的网络流量不会被 eBPF 程序误导入租户 B 的命名空间。依赖 XDP 与 TC 程序在 hook 点执行源/目的 IP 与 cgroup 校验。
• 控制平面隔离： eBPF Map 中存储的连接跟踪表、负载均衡规则必须按租户 ID 分片。禁止跨租户遍历 Map 条目。
• 观测隔离： 通过 eBPF 的 cgroup_id 或 namespace_id 过滤，确保租户只能看到本租户的套接字事件与网络延迟数据。

3.2.2 内存隔离边界

• eBPF Map 隔离： 每个租户的 eBPF Map 必须绑定唯一的 btf_id 与 uid。内核通过 bpf_map_lookup_elem 的权限检查阻止越权访问。
• Per-CPU 数据隔离： 使用 BPF_F_NO_PREALLOC 标志时，需防止租户通过内存耗尽攻击影响其他租户的 eBPF 程序执行。
• 栈与辅助函数隔离： eBPF 验证器确保辅助函数（如 bpf_get_current_pid_tgid）返回的数据不会泄露其他租户的进程上下文。

3.2.3 文件系统隔离边界

• BPF 文件系统 (bpffs) 隔离： 挂载点 /sys/fs/bpf 下的目录结构必须按租户划分，例如 /sys/fs/bpf/tenant-{id}/。使用 mount namespace 实现目录级可见性控制。
• eBPF 程序固定与生命周期： 租户只能 pin/unpin 自己目录下的 eBPF 程序与 Map。内核在 bpf_obj_pin 系统调用中检查目录所有权。
• Tracefs 与 Debugfs 访问： 禁止租户直接读取 /sys/kernel/debug/tracing 中的原始 trace 事件，必须通过 eBPF 程序经 Map 输出过滤后的数据。

3.3 安全威胁模型

基于上述隔离边界，我们定义以下安全威胁模型。该模型将作为后续控制平面分层设计的威胁输入。

3.4 威胁模型与隔离边界的映射关系

下图展示了三维隔离边界与主要安全威胁之间的对应关系，以及 eBPF 控制平面需要介入的防御点：

3.5 隔离需求对控制平面的约束

基于上述威胁模型，eBPF 控制平面必须满足以下非功能性需求：

1. 强制身份认证： 每个 eBPF 程序加载请求必须携带租户身份令牌，控制平面在 bpf() 系统调用路径上通过 LSM 程序校验令牌有效性。
2. Map 访问控制列表 (ACL)： 每个 eBPF Map 关联一个 ACL，明确允许哪些租户的 eBPF 程序执行 lookup、update、delete 操作。
3. 资源配额管理： 控制平面维护每个租户的 eBPF 程序数量、Map 大小、指令数上限，超过配额时拒绝加载请求。
4. 审计与可追溯： 所有跨租户的 eBPF 程序交互（如 Map 共享）必须记录审计日志，日志包含租户 ID、操作类型、时间戳。
5. 最小权限原则： eBPF 程序默认只能访问本租户的 Map 与网络命名空间，跨租户访问必须显式授权。