OVN ACL 表

ovn ACL 表可以直接绑定到 LSP， Port Group， Logical Switch

为了维护方便，一般都直接绑定到 Port Group， Logical Switch 。

关于安全组的设计，安全组中包含一组 ACL。组内的 ACL 直接绑定到 Port Group.

所以以安全组的名字会建立一个 Port Group，哪个虚拟机的网卡绑定了这个安全组，就会直接维护到 Port Group 中。

而 ACL 直接绑定到 logical switch。

那个 acl 和安全组的问题，安全组的规则会下发到 ovs 的 table=44 里，然后刚开始子网 acl 被下发到 table=17 里，这时候如果子网 acl drop，就先过 table 17 直接丢了，都不会到 table 44。然后把子网acl 删了重新加上，它又被下发到 table 44 里面了，这时候安全组和子网 acl 都在同一个 table=44 中，安全组优先级比子网 acl 高，这时候即使子网 acl 是 drop ，只要它匹配到安全组，安全组优先级更好就会放行，后面的低优先级的子网 acl 就不会生效。

2. 安全组的逻辑设计

目前是基于 pod annos 来配置安全组，同时有一个 crd 来维护安全组规则


# crd

type SecurityGroup struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty"`

	Spec   SecurityGroupSpec   `json:"spec"`
	Status SecurityGroupStatus `json:"status"`
}

type SecurityGroupSpec struct {
	IngressRules          []*SgRule `json:"ingressRules,omitempty"`
	EgressRules           []*SgRule `json:"egressRules,omitempty"`
	AllowSameGroupTraffic bool      `json:"allowSameGroupTraffic,omitempty"`
}

type SecurityGroupStatus struct {
	PortGroup              string `json:"portGroup"`
	AllowSameGroupTraffic  bool   `json:"allowSameGroupTraffic"`
	IngressMd5             string `json:"ingressMd5"`
	EgressMd5              string `json:"egressMd5"`
	IngressLastSyncSuccess bool   `json:"ingressLastSyncSuccess"`
	EgressLastSyncSuccess  bool   `json:"egressLastSyncSuccess"`
}


# pod annotation

ovn.kubernetes.io/port_security: 'true' 
ovn.kubernetes.io/security_groups: 'sg-example'

当通过 pod annotation 配置安全组时，

当不存在安全组时，external id 中的安全组引用均为 false，或不存在。 lsp 的 port_security 字段应为空

而且 address set 以及 port group 中对安全组的引用也应该被清理

以及默认的 deny all 也应该被清理

kube-ovn ACL 的应用

OVN ACL 表

2. 安全组的逻辑设计