租户隔离， 第一层内网

私有云场景下，租户隔离是安全的第一步，不同部门，业务，测试，开发使用不通的vpc，日常绝大部分场景都强制在各自的vpc内部。

由于网络隔离开了，在办公网和内部公网是无法基于一些扫描工具来轻易获取到开发的端口暴露的信息的。
也不会给demo开发，测试，带来额外的工作负担。

内部公网， 第二层 内网

vpc内部的集群如果需要暴露到内部公网，则通过端口转发，LB 等方式只暴露一个ip：端口出来，这些应用肯定是相对比较成熟的应用，已经集成了用户校验，ip白名单，等安全限制。

公网访问

这个需要IT在核心路由做限制，对指定的公网ip 和端口进行审计。

那么问题来了？

vpc 内网需要启用安全组么？

我感觉不大需要。 首先vpc 决定了vpc内部只有某些个租（用）户可以访问，已经限制在几个人的范围内。
而且用户管理一般都是TL负责权限管理的，如果demo测试操作的是敏感信息。那么单独建一个临时租户进行测试即可，vpc 和 内部公网是完全隔离的。

用户用户测试的ip 和 端口非常频繁，配置指定ip和端口的开放， 对于测试和开发人员来说是非常繁琐的事情，每变动一次ip和端口就要修改一次安全组，而且安全组还要运维人员清理，甚至安全组和配置要测试|开发和运维对接一下才能完成，这种高频率，高碎片化，多次重复的事情对运维人员的成长也是极为不利的。

如果要解放运维，那么就要定制一套关于安全组的配置工具，还需要在内部推广，投入一定的学习时间。

而且ovs安全组限制了L2的vm k8s的ipvlan|veth-pair 这种cni模型必须使用aap机制。这样就导致pod ip 和 k8s node有一定的绑定关系，对于statefulset这种需要保留ip的场景，导致statefulset的pod 固定在了一些node上，这样就导致pod无法在所有node上随意迁移，导致高可用降低。 否则 pod ip 对应的mac就会变更，导致流表变动的频率变高。

aap 虚拟port 依赖 ovs 主网卡的parent port，而虚拟port的mac是跟随主port的。 所以l2 ipvlan | veth pair cni 的 ip mac保持不变的前提就是 虚拟机port 不漂移，那么就保持在了原来的node的主网卡上。 这样无需变更虚拟ip 以及 安全组。

而且安全组的配置在虚拟port 和 主 port都有配置，这个维护也是非常繁琐，但是私有云场景下，收益极低的事情。 安全组做到的限制，vpc默认都已经做到了。

ovs的主 port 迁移 是可以做到 ip 和 mac 不变的， openstack vm 热迁移实测，保持ping 也就丢2-3个包。

底层依赖ovs，L2 ipvlan|veth-pair的跨node（vm）迁移是无法保持mac不变的。 由于有dns，负载均衡，只要ip不变，其实丢几个包影响并不大。