至此我们 apply 的网络策略被写入到 map 中。

接下来看下 ebpf 程序有任何使用该策略。

还记得在Kubernetes 网络学习之 Cilium 与 eBPF[15]中我们分析容器发出的数据包，被LXC BPF Ingress程序处理。这里不再赘述，处理流程可以看那篇文章。

我们先查看死星的 endpoint id 和 identity 分别为863和2033。

kubectl get ciliumendpoint -n defaultNAME ENDPOINT ID IDENTITY ID INGRESS ENFORCEMENT EGRESS ENFORCEMENT VISIBILITY POLICY ENDPOINT STATE IPV4 IPV6tiefighter 2216 29439 ready 10.0.0.123deathstar-7848d6c4d5-58jc8 863 2033 ready 10.0.0.111xwing 775 5513 ready 10.0.0.209

使用 endpoint id 通过通过命令查看为死星配置的网络策略，可以看到其中的两条 ingress 的策略，其代理端口19313，这个端口就是 Cilium 中 L7 代理的监听端口。

kubectl exec $agent -n kube-system -c cilium-agent -- cilium bpf policy get 863POLICY DIRECTION LABELS (source:key[=value]) PORT/PROTO PROXY PORT BYTES PACKETSAllow Ingress reserved:host ANY NONE 0 0 reserved:kube-apiserverAllow Ingress k8s:app.kubernetes.io/name=deathstar 80/TCP 19313 0 0 k8s:class=deathstar k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default k8s:io.cilium.k8s.policy.cluster=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default k8s:org=empireAllow Ingress k8s:app.kubernetes.io/name=tiefighter 80/TCP 19313 0 0 k8s:class=tiefighter k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default k8s:io.cilium.k8s.policy.cluster=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default k8s:org=empireAllow Egress reserved:unknown ANY NONE 0 0

BPF 程序处理流量在检查策略时bpf_lxc.c#L1842[16]，检查配置的策略带有代理端口执行POLICY_ACT_PROXY_REDIRECT将流量重定向给代理（端口19313，地址为主机地址）。

Cilium agent 提供了 xds server 实现，通过 Unix Domain Socket/var/run/cilium/xds.sock与 proxy 进行通信，下发配置。

我们参考cilium-bugtool的dump 源码[17]，dump 代理的配置。

kubectl exec $agent -n kube-system -c cilium-agent -- curl -s --unix-socket /var/run/cilium/envoy-admin.sock http://admin/config_dump?include_eds

从配置 config.json 中可以看到 Cilium 在 envoy proxy 中实现了如下三个不同类型的过滤器（Filter）：

监听器过滤器（Listener Filter）`cilium.BpfMetadata`[18]会从几个数据源中准备元数据：策略、监听器设置、请求方的标识等。数据源包括 xds 配置、BPF mapcilium_ipcache、cilium_ct4_global（ct：connection tracking。当然还包括 ct6 相关的 map）。

从数据源中获取的数据保存在 socket option 中（proxy 源码bpf_metadata.cc#L364[19]），作为上下文元数据的在其他的过滤器中使用。

xds filter 配置，这里提供了 bpf map 的根目录/sys/fs/bpf，以及is_ingress: true表示当前 filter 是在入口监听器上（ingress listener）：

{ "name": "cilium.bpf_metadata", "typed_config": { "@type": "type.googleapis.com/cilium.BpfMetadata", "bpf_root": "/sys/fs/bpf", "is_ingress": true }

xds network policy 配置（截取了 proxy 的部分配置），从配置中可以找到 endpoint 的 IP 和 id，以及前面我们设置的规则[20]：

{ "@type": "type.googleapis.com/cilium.NetworkPoliciesConfigDump", "networkpolicies": [ { "endpoint_ips": [ "10.0.0.111" ], "endpoint_id": "863", "ingress_per_port_policies": [ { "port": 80, "rules": [ { "http_rules": { "http_rules": [ { "headers": [ { "name": ":method", "safe_regex_match": { "google_re2": {}, "regex": "POST" } }, { "name": ":path", "safe_regex_match": { "google_re2": {}, "regex": "/v1/request-landing" } } ] } ] } } ] } ], "egress_per_port_policies": [ {} ], "conntrack_map_name": "global" }, ...}

Mapcilium_ipcache，可以通过连接信息中的 IP 地址获取身份标识，如死星的`identity`[21]为2033（见 proxy 源码bpf_metadata.cc#L165[22]）：

kubectl exec $agent -n kube-system -c cilium-agent -- cilium bpf ipcache listIP PREFIX/ADDRESS IDENTITY10.0.0.67/32 identity=1 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=010.0.0.111/32 identity=2033 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=010.0.0.123/32 identity=29439 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=010.0.0.243/32 identity=4 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=010.0.0.160/32 identity=19608 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=010.0.0.209/32 identity=5513 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0192.168.1.13/32 identity=1 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=00.0.0.0/0 identity=2 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0

Mapcilium_ct4_global，从连接跟踪（connection tracking）中获取请求方的identity（SourceSecurityID 29439，钛战机的标识）：

cilium bpf ct list globalTCP OUT 10.0.0.123:48954 -> 10.0.0.111:80 expires=58774 RxPackets=4 RxBytes=435 RxFlagsSeen=0x1b LastRxReport=58764 TxPackets=6 TxBytes=522 TxFlagsSeen=0x1b LastTxReport=58764 Flags=0x0013 [ RxClosing TxClosing SeenNonSyn ] RevNAT=4 SourceSecurityID=29439 IfIndex=0TCP IN 10.0.0.67:33988 -> 10.0.0.111:80 expires=58776 RxPackets=6 RxBytes=659 RxFlagsSeen=0x1b LastRxReport=58766 TxPackets=4 TxBytes=386 TxFlagsSeen=0x1b LastTxReport=58766 Flags=0x0013 [ RxClosing TxClosing SeenNonSyn ] RevNAT=0 SourceSecurityID=29439 IfIndex=0TCP IN 10.0.0.123:48954 -> 10.0.0.111:80 expires=80364 RxPackets=6 RxBytes=522 RxFlagsSeen=0x1b LastRxReport=58764 TxPackets=0 TxBytes=0 TxFlagsSeen=0x00 LastTxReport=0 Flags=0x0051 [ RxClosing SeenNonSyn ProxyRedirect ] RevNAT=0 SourceSecurityID=29439 IfIndex=0过滤器

过滤器（Filter）`cilium.NetworkFilter`[23]工作在 L4，用于处理已建立的链接，应用端口级的策略，即 L4 策略。

从上下文元数据中保存的 endpoint 相关的策略中查找与目标端口相关的策略，检查请求方证书中的 sni 和请求方的身份标识 identity 是否在白名单中，见 proxy 源码network_filter.cc#L169[24]。

假如策略上设置了 L7 的协议，会使用 Golang 编写的解析器对 L7 的数据进行解析。

在本示例中并未使用 L4 的策略。

HTTP 过滤器（HTTP Filter）`cilium.L7Policy`[25]是本文的重点，但相对其他两个过滤器来说逻辑就简单多了。

"http_filters": [ { "name": "cilium.l7policy", "typed_config": { "@type": "type.googleapis.com/cilium.L7Policy", "access_log_path": "/var/run/cilium/access_log.sock" } }

在过滤器对 HTTP 请求头进行解码时（见 proxy 源码l7policy.cc#L97[26]），依然是从上下文元数据中获取策略等内容。拿到策略后，与请求方（对于这里 ingress 的场景检查请求方，如果是 egress 的场景，检查上游的标识）的标识、请求头的信息进行比对，决定放行还是拒绝请求。

整篇看下来，Cilium 在处理 L7 流量上的实现还是比较复杂的，牵扯多个组件协同。eBPF 在 L3/L4 流量处理上有着优异的性能优势，但是对 L7 流量处理仍然无法脱离 sidecar 代理（不论 sidecar 是 per pod 还是 per node）。而 L7 流量处理也恰恰有着非常多的使用场景，不仅仅是 HTTP 协议。

[1]使用 Cilium 增强 Kubernetes 网络安全:https://atbug.com/enhance-kubernetes-network-security-with-cilium/

[2]Envoy Proxy:https://github.com/cilium/proxy

[3]Debug 阶段:#debug

[4]深入探索 Cilium 的工作机制:https://atbug.com/deep-dive-into-cilium/#网络策略

[5]#enableK8sWatchers:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/pkg/k8s/watchers/watcher.go#L525

[6]#ciliumNetworkPoliciesInit:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/pkg/k8s/watchers/cilium_network_policy.go#L85

[7]#addCiliumNetworkPolicyV2:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/pkg/k8s/watchers/cilium_network_policy.go#L159

[8]#PolicyAdd:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/daemon/cmd/policy.go#L224

[9]Daemon:https://atbug.com/deep-dive-into-cilium/#agent

[10]#policyAdd:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/daemon/cmd/policy.go#L249

[11]PolicyReactionEvent.Handle:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/daemon/cmd/policy.go#L454

[12]EndpointRegenerationEvent#Handle:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/pkg/endpoint/events.go#L27

[13]Endpoint.regenerate:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/pkg/endpoint/policy.go#L286

[14]Endpoint.regenerateBPF:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/pkg/endpoint/bpf.go#L584

[15]Kubernetes 网络学习之 Cilium 与 eBPF:https://atbug.com/learn-cilium-and-ebpf/#第-2-步pod1-lxc-bpf-ingress

[16]bpf_lxc.c#L1842:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/bpf/bpf_lxc.c#L1842

[17]dump 源码:https://github.com/cilium/cilium/blob/f9bdd00c4910bfe3bac3b208fdfbb9452487e776/bugtool/cmd/root.go#L505

[18]cilium.BpfMetadata:https://github.com/cilium/proxy/blob/v1.23/cilium/bpf_metadata.cc

[19]bpf_metadata.cc#L364:https://github.com/cilium/proxy/blob/v1.23/cilium/bpf_metadata.cc#L364

[20]规则:#设置策略

[21]identity:https://atbug.com/deep-dive-into-cilium/#端点-endpoint

[22]bpf_metadata.cc#L165:https://github.com/cilium/proxy/blob/v1.23/cilium/bpf_metadata.cc#L165

[23]cilium.NetworkFilter:https://github.com/cilium/proxy/blob/v1.23/cilium/network_filter.cc

[24]network_filter.cc#L169:https://github.com/cilium/proxy/blob/v1.23/cilium/network_filter.cc#L169

[25]cilium.L7Policy:https://github.com/cilium/proxy/blob/v1.23/cilium/l7policy.cc

[26]l7policy.cc#L97:https://github.com/cilium/proxy/blob/v1.23/cilium/l7policy.cc#L97