安全组是租户隔离的关键执行层，需嵌入网络模型选择（如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）