安全组是租户隔离的关键执行层，需嵌入网络模型选择（如VXLAN）、租户标识绑定（项目/命名空间级）、策略粒度控制（最小权限精确放行）和底层驱动协同（OVS/iptables同步生效）四环节。
安全组本身不是租户隔离的终点，而是关键执行层。真正实现严格隔离，需要把安全组配置嵌入到网络模型选择、租户标识绑定、策略粒度控制和底层驱动协同这四个环节里。
选对网络模式：VXLAN是严格隔离的前提
VLAN模式受限于4096个ID上限，且依赖物理交换机配合，租户规模稍大就容易冲突或配置滞后；Flat网络则完全无隔离能力。VXLAN通过24位VNI（最多1677万段）在IP网络上构建逻辑二层隧道，每个租户可独占一个VNI，广播域天然隔离，不依赖底层硬件透传——这是实现严格租户隔离的网络基础。
- Neutron中创建租户网络时，明确指定provider:network_type=vxlan
- 确保所有计算节点和网络节点的openvswitch都启用vxlan端口，并配置正确UDP端口（默认8472）
- 避免混用VLAN与VXLAN网络，否则Neutron可能将不同租户流量误导向同一物理网段
绑定租户上下文：让每条规则只属于一个租户
安全组规则必须与租户身份强绑定，不能共用全局规则集。OpenStack中，安全组（security group）是项目（project）级别的资源，创建时需指定--project参数；Kubernetes中则需配合NetworkPolicy的namespace限定和podSelector精准匹配。
- 禁止创建无project或无namespace的安全组/策略
- 拒绝使用default安全组作为通用模板，每个租户应有独立命名的安全组（如tenant-a-web-sg）
- 规则中源/目标地址尽量用租户内子网CIDR，而非0.0.0.0/0或宽泛IP段
细化规则粒度：从“允许Web访问”到“仅允许A租户API网关调用B租户服务端口”
严格隔离不是靠“全通”或“全拒”，而是靠最小权限原则下的精确放行。例如，租户A的前端Pod要访问租户B的后端Service，不能简单开放B租户整个子网的TCP 8080，而应：
- 在Neutron中，为B租户创建专用安全组（如tenant-b-api-sg），只允许来自A租户特定子网+特定端口的入向流量
- 在Kubernetes中，NetworkPolicy需同时指定policyTypes: [Ingress]、ingress.from.namespaceSelector.matchLabels: {tenant: "a"}、ingress.ports.port: 8080
- 禁用基于IP的宽泛规则，优先使用标签、命名空间、服务名等逻辑标识符
驱动层协同：OVS流表与iptables需同步生效
安全组最终由Open vSwitch（OVS）或Linux iptables执行。若Neutron下发了规则但OVS未刷新流表，或iptables规则被其他工具覆盖，隔离即失效。需确认：
- neutron-openvswitch-agent日志中无“failed to update security group”类错误
- 在计算节点执行ovs-ofctl dump-flows br-int | grep “dl_vlan”或“tun_id”验证VXLAN隧道ID是否参与匹配
- 检查iptables -L neutron-filter-top是否存在，且链引用关系完整（如neutron-openvswi-sg-xxx链是否挂载到neutron-openvswi-o）
