Cilium 如何处理 L7 流量
  • 11 June, 2023

Cilium 如何处理 L7 流量

还记得在 使用 Cilium 增强 Kubernetes 网络安全 示例中，我们通过设置网络策略限制钛战机 tiefighter 访问死星 deathstar 的 /v1/exhaust-port 端点，但放行着陆请求 /v1/request-landing。在提起 Cilium 时，都说其是使用 eBPF 技术推动的用于提供、保护和观察容器工作负载之间的网络连接的开源软件。eBPF 可以处理 L3/4 的数据包，但是对复杂的 L7 的协议处理的成本比较高，并且无法应对 L7 协议策略的灵活性。Cilium 引入 Envoy Proxy（Cilium 定制的发行版）作为 L7 代理，来处理该场景。

那 Cilium 是如何处理 L7 流量的呢？今天就让我们一探究竟。

注，这篇的内容是基于目前最新的 Cilium 1.13.3 和 proxy 1.23.9，不同版本间会有差异。

在开始之前先搭建先前的“星球大战”环境，或者你也可以直接跳到 Debug 阶段。

环境搭建

集群 

export INSTALL_K3S_VERSION=v1.27.1+k3s1
curl -sfL https://get.k3s.io | sh -s - --disable traefik --disable local-storage --disable metrics-server --disable servicelb --flannel-backend=none --write-kubeconfig-mode 644 --write-kubeconfig ~/.kube/config

安装 Cilium 

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/master/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

cilium install

安装示例应用 

kubectl apply -n default -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: deathstar
  labels:
    app.kubernetes.io/name: deathstar
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    org: empire
    class: deathstar
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deathstar
  labels:
    app.kubernetes.io/name: deathstar
spec:
  replicas: 1
  selector:
    matchLabels:
      org: empire
      class: deathstar
  template:
    metadata:
      labels:
        org: empire
        class: deathstar
        app.kubernetes.io/name: deathstar
    spec:
      containers:
      - name: deathstar
        image: docker.io/cilium/starwars
---
apiVersion: v1
kind: Pod
metadata:
  name: tiefighter
  labels:
    org: empire
    class: tiefighter
    app.kubernetes.io/name: tiefighter
spec:
  containers:
  - name: spaceship
    image: docker.io/tgraf/netperf
---
apiVersion: v1
kind: Pod
metadata:
  name: xwing
  labels:
    app.kubernetes.io/name: xwing
    org: alliance
    class: xwing
spec:
  containers:
  - name: spaceship
    image: docker.io/tgraf/netperf
EOF

设置策略 

kubectl apply -n default -f - <<EOF
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L7 policy to restrict access to specific HTTP call"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/v1/request-landing"
EOF

测试 

kubectl exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port
#Access denied
kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
#Ship landed

查看 pod 信息。

kubectl get po -o wide -n default
NAME                         READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
deathstar-7848d6c4d5-58jc8   1/1     Running   0          6h57m   10.0.0.111   ubuntu-dev3   <none>           <none>
xwing                        1/1     Running   0          6h57m   10.0.0.209   ubuntu-dev3   <none>           <none>
tiefighter                   1/1     Running   0          6h57m   10.0.0.123   ubuntu-dev3   <none>           <none>

后面 debug 的操作我们会直接在 cilium 的 agent pod 进行。

agent=$(kubectl get po -l app.kubernetes.io/name=cilium-agent -n kube-system -o jsonpath='{.items[0].metadata.name}')

Debug

先贴上总结的图。

怎么下手呢？

在 深入探索 Cilium 的工作机制 时，我们对 Cilium 的网络策略处理机制一笔带过：

Cilium Agent 中运行着大量的 watcher，其中一个就是 CiliumNetworkPolicy watcher。当策略创建或者更新时，Agent 会对策略进行转换并将规则存储到 BPF Map 中。在网络通信时，BPF 程序会对网络流量进行检查并决定应当允许或者拒绝访问。

实际上这里的处理比较复杂，我们从 watcher 的初始化入手。

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

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

eBPF

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

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

kubectl get ciliumendpoint -n default
NAME                         ENDPOINT ID   IDENTITY ID   INGRESS ENFORCEMENT   EGRESS ENFORCEMENT   VISIBILITY POLICY   ENDPOINT STATE   IPV4         IPV6
tiefighter                   2216          29439         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.123
deathstar-7848d6c4d5-58jc8   863           2033          <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.111
xwing                        775           5513          <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.209

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

kubectl exec $agent -n kube-system -c cilium-agent -- cilium bpf policy get 863
POLICY   DIRECTION   LABELS (source:key[=value])                                              PORT/PROTO   PROXY PORT   BYTES   PACKETS
Allow    Ingress     reserved:host                                                            ANY          NONE         0       0
                     reserved:kube-apiserver
Allow    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=empire
Allow    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=empire
Allow    Egress      reserved:unknown                                                         ANY          NONE         0       0

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

Cilium Proxy

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

我们参考 cilium-bugtool 的 dump 源码，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
  • filter
  • http filter

监听器过滤器

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

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

元数据数据源

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，以及前面我们设置的 规则：

{
 "@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"
  },
  ...
}

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

kubectl exec $agent -n kube-system -c cilium-agent -- cilium bpf ipcache list
IP PREFIX/ADDRESS   IDENTITY
10.0.0.67/32        identity=1 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0
10.0.0.111/32       identity=2033 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0
10.0.0.123/32       identity=29439 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0
10.0.0.243/32       identity=4 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0
10.0.0.160/32       identity=19608 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0
10.0.0.209/32       identity=5513 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0
192.168.1.13/32     identity=1 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0
0.0.0.0/0           identity=2 encryptkey=0 tunnelendpoint=0.0.0.0 nodeid=0

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

cilium bpf ct list global
TCP 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=0
TCP 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=0
TCP 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 工作在 L4，用于处理已建立的链接，应用端口级的策略，即 L4 策略。

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

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

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

HTTP 过滤器

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

"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），依然是从上下文元数据中获取策略等内容。拿到策略后，与请求方（对于这里 ingress 的场景检查请求方，如果是 egress 的场景，检查上游的标识）的标识、请求头的信息进行比对，决定放行还是拒绝请求。

总结

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

（转载本站文章请注明作者和出处乱世浮生，请勿用于任何商业用途）

comments powered by Disqus

目录

推荐阅读

深入探索 Cilium 的工作机制
深入探索 Cilium 的工作机制
 Kubernetes 网络学习之 Cilium 与 eBPF
Kubernetes 网络学习之 Cilium 与 eBPF
 使用 Cilium 增强 Kubernetes 网络安全
使用 Cilium 增强 Kubernetes 网络安全