基于eBPF的微服务网络安全(Cilium 1)

基于eBPF的微服务网络安全

翻译自：Network security for microservices with eBPF

一些开源的kubernetes工具已经开始使用eBPF，这些工具大多数与网络，监控和安全相关。

本文不会涵盖eBPF的方方面面，只作为一个入门指南，包括Linux内核的BPF概念，到将该功能加入到微服务环境的优势，以及当前使用到该功能的工具，如Cilium或Weave。

理解eBPF

Berkely Packet Filters，简称BPF，是一个指令集，在1992年由Steven McCanne和Van Jacobso首次引入，通常用于给应用(如tcpdump)提供包过滤功能，并长期保持在Linux内核中。

BPF可以看作是一个简单的虚机，由此抽象出的机器只有少数寄存器，栈空间，一个隐式程序计数器以及一个允许与内核的其余部分共同作用的辅助函数的概念。

内核中的VM负责将bfp字节代码转换为底层可以理解的结构，并提供包过滤功能。

但在此之前，为了执行报文过滤，需要将报文拷贝到用户空间，这样会导致效率低下，而且资源浪费严重。

校验器(verifier)会校验程序是否会触发循环，并保证程序能够停止(不会产生死循环)。

最近几年，Linux社区从内核中移除了经典的BPF(cBPF，功能仅限于报文过滤和监控)解析器，并引入了一个新的指令集，称为eBPF。

扩展的BPF带来了更多的灵活性和可编程性，增加了新的使用场景，如跟踪，外部使用bpf系统调用，安全访问内核内存或快速解析等，并更新了即时(JIT)编译器，为运行在本机上的程序翻译eBPF。

还可以将bpf程序附加到其他内核对象上(cBPF只能附加到socket上用于socket过滤)。可附加到的对象为：Kprobes, Tracepoints, Network schedules, XDP (eXpress Data Path)等，XDP用于与共享数据结构(map)配合使用，可以在用户空间和内核空间之间提供通信，或在不同的BPF程序间共享信息。

创建一个BPF程序

eBPF的一个重要特性是能够使用高级语言(如C)来实现程序。LLVM有一个eBPF后端，用于编辑包含eBPF指令的ELF文件，前端(如clang)可以用于生成程序。

在一个后端转换为字节码后，使用bpf()系统调用加载bpf程序，并校验安全性。JIT会将字节码编译进CPU架构中，并将该程序附加到内核对象上，当这些对象发生事件时会触发程序的执行(例如，当从一个网络接口发送报文时)。

可以参考如下资料编写eBPF程序，：

• Using clang/LLVM to compile programs
• Go bindings for creating BPF programs
• Go library that provides utilities for loading, compiling, and debugging eBPF programs

IPTables下的容器安全策略

历史上，容器的运行时为Docker，通过在容器主机上配置IPTables来实现安全策略以及NAT规则。

下图中进行了5个阶段：

• connect()系统调用
• 构造报文
• 通过vETH对转发报文
• 在主机上应用iptables
• 丢弃或转发报文

使用iptables时，可以为每个实例配置策略，但仅限于层3和层4。需要重新构包，且需要按顺序处理iptables表项来对处理需要转发的报文。

eBPF下的容器安全策略

eBPF策略能够在整个协议栈或构包之前应用于系统调用()，而不受使用iptables的限制。由于eBPF附加到了容器网络命名空间中，所有的通信都会被eBPF截获和过滤。

此外还能根据程序级别的动作应用安全策略。对于每个微服务，不仅仅可以在L3和L4配置策略，也可以在L7配置策略，如REST GET/POST/PUT/DELETE或指定特定路径，如/service1, /restricted。

使用eBPF替换iptables

从linux内核贡献者的手上学习为什么内核社区要取代iptables，了解kubernetes 的kube-proxy面临的问题，或为什么在容器中基于IP地址和端口使用策略不是一个好的方式。

一部分使用eBPF特性实现的开源kubernetes工具实现了高性能和低延时，特别用于监控，安全和网络领域。

Cilium：动态网络控制和可视化

Cilium网络项目大量使用了eBPF，为基于容器的系统提供了路由和网络流量的过滤。它可以在不修改内核的前提下动态地生成和应用规则。

上述例子中的L3/L4策略仅允许app2通过80端口访问app1，不允许app3访问app1。

[{
    endpointSelector: {matchLabels:{id:app1}},
    ingress:[{
        fromEndpoints:[
            {matchLabels:{id:app2}}
        ],
        toPorts:[{
            ports:[{ports:80, protocol:tcp}]
        }]
    }]
}]

我们也可以在调用层采用更严格的安全策略，例如限制能够访问/public路径，但不能访问/restricted 路径。

Cilium如何工作

每个主机运行一个代理，将网络策略定义转换为BPF程序(而非管理iptables)。这些程序会被加载到内核中，然后附加到容器的虚拟以太网设备上，当执行这些程序时，会对每个发送和接收的报文应用这些规则。

由于BPF运行在Linux内核中，因此，能够在不修改应用代码或容器配置的前提下使用和更新Cilium的安全策略。

更多参见：

• API-aware Networking andSecurity
• Component overview
• 如果要了解Cilium 如何使用eBPF，可以参考BPF and XDP reference guide

TIPS：

• Cilium 对系统的要求比较高，例如内核的版本要求Linux kernel >= 4.9.17，更多参加官方文档

• 受限于eBPF比较新，且需要的内核版本较高，因此目前还没有被kubernetes大规模推广，但该网络方案是一个大趋势。目前calico已经支持eBPF模式(不建议生产使用)，且阿里云的Terway插件也是基于eBPF。

• 更多参见官方文档