多租户环境资源隔离需从系统初始化阶段分层设防：一、文件系统启用ACL与noexec/nosuid/nodev挂载；二、运行时用systemd slice或容器硬限CPU/内存/GPU；三、网络绑定本地地址+network namespace+防火墙策略；四、控制面集成统一认证、RBAC、vCluster及全审计日志。
服务器系统安装时配置多租户环境的资源隔离，关键不是“装完再补”，而是从系统初始化阶段就规划好隔离边界。核心思路是：分层设防——操作系统层做权限与文件隔离，运行时层控资源配额，网络层保通信独立，控制面层管访问权。不同场景下侧重点不同，但以下四类配置是通用基础。
一、文件系统与访问权限隔离（Linux 系统必做）
避免租户间误读、误删或越权访问，不能只靠传统 chmod/chown。
- 启用 ACL（Access Control List）：在根数据目录（如
/srv/tenants）上为每个租户用户单独授权，例如：setfacl -m u:tenant-a:rwx /srv/tenants/tenant-asetfacl -m u:tenant-b:--- /srv/tenants/tenant-a - 设置默认 ACL（default ACL）：确保租户目录内新建文件/子目录自动继承权限，命令加
-d参数即可； - 禁用 group 冗余访问：避免将多个租户加入同一组后导致隐式互通；
- 挂载选项加固：对租户数据分区使用
noexec,nosuid,nodev挂载，防止执行恶意程序或提权行为。
二、运行时资源硬限制（CPU / 内存 / GPU）
防止某租户进程耗尽资源影响他人，需在系统级而非应用级设限。
- 使用 systemd 的 scope 或 slice：为每个租户创建独立的
tenant-a.slice，通过MemoryMax、CPUQuota等参数约束； - 容器化部署（推荐）：Docker 或 Podman 启动时指定
--memory=4G --cpus=2 --gpus device=0,1，天然隔离进程、文件系统和网络命名空间； - GPU 多租户：NVIDIA Container Toolkit 配合 MIG（Multi-Instance GPU）或 vGPU 技术，把单卡切分为多个逻辑 GPU 实例，分配给不同租户；
- 避免仅依赖 ulimit：它只作用于 shell 进程树，无法约束后台服务或 fork 出的守护进程。
三、网络与端口隔离（防横向渗透）
租户服务即使在同一台机器，也应像在不同主机上一样通信受控。
- 绑定监听地址：Web 或 API 服务配置为
127.0.0.1:8080而非0.0.0.0:8080，再通过反向代理（如 Nginx）按域名或路径路由； - 使用 network namespace：手动创建隔离网络空间，配合 veth pair 和网桥，实现租户独占 IP 段与路由表；
- 防火墙策略细化：用
nftables或iptables限制租户进程只能访问指定目标端口（如只允许 tenant-a 访问 DB 服务的 5432）； - 云环境优先选 VRF 或 VXLAN：如 H3C 防火墙用 VRF 解决 AWS 多租户 IP 重叠问题，OpenStack Neutron 用 VLAN 或 VXLAN 实现租户二层隔离。
四、控制面与身份隔离（防越权操作）
租户不仅不该看到别人的数据，也不该拥有不该有的管理能力。
- 统一身份认证：集成 Kerberos 或 LDAP，所有服务（SSH、Kubernetes、Storm）共用一套用户凭证；
- 细粒度权限模型：Kubernetes 中不用 Namespace + RBAC 就算完事，要结合
NetworkPolicy、PodSecurityPolicy（或新版PodSecurity Admission）； - 虚拟控制面：对高敏感或多团队场景，用 vCluster 创建轻量级虚拟 Kubernetes 集群，租户获得独立 etcd 和 API Server，可自由装 CRD，互不影响；
- 审计日志全开启：记录 sudo 命令、ACL 修改、容器启动等关键操作，日志集中收集（如 Loki + Grafana），便于事后追溯。
实际部署中，不建议堆砌全部方案。中小团队可先落地 ACL + 容器资源限制 + Nginx 反向代理隔离；金融或 SaaS 类客户交付，则必须叠加 vCluster + Kata Containers + 网络策略三层防护。隔离强度始终要匹配业务风险等级。
