论文：BASTION: A Security Enforcement Network Stack for Container Networks

背景知识

容器网络

单主机容器网络：容器根据Linux network namespace进行网络隔离，同主机的容器通过veth pair连接到虚拟机交换机或网桥上，构成单主机的容器网络，相同主机的容器可以通过网桥通信。

CoreOS发布容器网络标准（CNI, Container Network Interface），为容器网络提供统一的接口。

跨主机容器网络方案：

• Flannel: CoreOS针对k8s设计的容器网络方案，应用最广泛。传统的docker网络，每个节点的容器的网络IP被所在节点的docker服务分配，不同节点的docker之间不存在信息交换的情况，不同节点的容器有几率被分配到相同的IP地址上。Flannel会重新规划集群所有节点容器的IP地址，使它们能在同一个集群内相互通信。

  

  通信过程：

  1. 数据从源容器出发，从宿主机的docker0虚拟网卡转发到flannel0虚拟网卡；（docker0是虚拟网桥）
  2. Etcd(分布式键值数据库)维护节点间路由关系的路由表，Flannel通过该路由表找到接收方对应节点，将数据包投递到该网卡上；（每台主机上flannel运行一个daemon进程flanneld，它可以在内核中创建路由表，flanneld进程通过读取etcd中的映射关系信息，决定隧道外层封装）
  3. 原数据包被源主机的flanneld服务进行UDP封装操作后根据路由表投递给目的节点的flanneld服务（通过VXLAN虚拟扩展局域网通信）

• Calico

论文内容

摘要

在这项工作中，我们对容器网络进行了安全分析，确定了由于容器化应用程序暴露不必要的网络操作而引起的一些问题，并讨论了它们的含义。然后，我们提出了一个新的高性能安全强制网络栈，称为BASTION，它通过一个智能容器感知通信沙箱扩展了容器托管平台。BASTION引入了（i）网络可见性服务，该服务为每个容器应用程序提供对可见网络拓扑的细粒度控制；（ii）流量可见性服务，它以点到点的方式安全地隔离和转发容器间的流量，防止该流量暴露到其他对等容器中。我们的评估证明了BASTION如何有效地缓解容器网络中的几种攻击，同时在单主机容器内提高了25.4%的总体性能，而跨主机容器通信的整体性能提高了17.7%。

引言

Tripwire的容器安全报告表明，2018年有60%的组织机构已经经历了容器安全事件，这些安全事件的发生主要是因为运营者只关注容器的快速部署而忽略了容器所存在的安全风险。

容器所遵循的共享内核模型架构同样会引入安全风险，评判其安全性能的好坏的因素在于主机操作系统能否对容器进行隔离。AppArmor, Seccomp, SELinux等方案设计通过阻止各种系统资源滥用提供容器间较强的隔离。一些商业产品引入了容器安全框架，能够在运行时监视容器并实施动态的控制策略。

虽然各种针对容器化应用的安全方案层出不穷，但很少有方案对应用访问容器网络进行限制。

这篇论文首先讨论了当前依赖于主机OS的网络堆栈和虚拟网络特性来提供容器网络安全策略可能产生的一些安全风险，并给出了五个例子来说明基于主机OS网络堆栈来管理容器生态间的通信存在的固有局限性。然后我们引入了BASTION，一个对容器网络堆栈隔离和保护的拓展。BASTION由manager和per-container network stacks组成，manager从活跃的容器收集网络和策略信息，然后在每个容器部署安全强制网络堆栈。在网络堆栈中，所有安全实施都是通过两个主要的安全服务进行的，即网络可见性服务和流量可见性服务。

依赖于容器间的依赖集合，网络可见性服务控制容器发现进程（container discovery process），过滤掉对依据依赖图无关的容器和主机访问。流量可见性服务控制容器和其他对等容器间的网络流量，同时对流量的来源进行验证，保证流量通过一个高效的转发机制在容器间传输，同时保证发送者和接收者之间网络通信隔离。任何时候容器环境的改变，manager都会动态地更新每个容器内的网络堆栈且不会影响容器所提供的服务。

论文贡献如下：

• 容器网络的安全评估，说明当前容器网络栈和安全机制中出现的安全挑战。
• 为容器引入了一种新的安全强制网络堆栈，它限制了容器网络的可见性，并以高性能隔离对等容器之间的网络流量。
• 介绍原型系统BASTION，包括分析它如何解决当前容器环境中的网络安全挑战。

背景和动机

容器网络

Docker使用桥接网络来进行容器间的通信（在同一个主机节点上），下面这张图展示了微服务架构以及它逻辑上的网络拓扑结构。（单机网络模式）

k8s容器编排系统：Kubernetes[26]支持跨多个节点（如物理主机服务器）管理大量Docker容器，使跨主机容器应用程序能够作为一个逻辑单元工作。因此，虽然Docker在同一主机（节点）内使用桥接网络，但Kubernetes使用各种覆盖网络（例如，Flannel[11]、Weave[55]、Calico[49]）来提供跨多个节点的容器间连接。例如，在Weave覆盖网络[55]中，每个节点都有一个称为Weave的特殊网桥接口，用于连接所有本地容器。在每个节点上运行的weave bridges在逻辑上作为一个网络连接起来。虽然Kubernetes使用Docker容器，但它没有使用Docker网络特性来管理网络流量控制。相反，它使用iptables单独应用网络策略。Calico[49]同样使用iptables应用网络和安全策略。如果运营商希望进一步加强安全性，他们可以使用Cilium[7]，这是一个安全扩展，它通过将所有网络流量重定向到其容器化安全服务（enjont）来执行API感知的访问控制（例如，HTTP方法）

Kubernetes容器网络模型

什么是vxlan

博客补充：

1. Docker启动时会在主机上自动创建一个docker0虚拟网桥，实际上是一个Linux网桥，可以理解为一个软件交换机，它会在挂载其上的接口之间进行转发。当创建一个Docker容器时，同时会创建一对vet pair接口，这对接口一端在容器内，即eth0，另一端在本地被挂载到docker0网桥，名称以veth开头。

2. VXLAN本质上是一种隧道技术，当源和目的之间有通信需求时，便在数据中心IP网络之上创建一条虚拟的隧道，透明转发用户数据。从服务器的角度看，VXLAN为它们将整个数据中心基础网络虚拟成了一台巨大的“二层交换机”，所有服务器都连接在这台虚拟二层交换机上。VXLAN支持VM的动态迁移，因为将虚拟机从一个“二层交换机”的一个端口换到另一个端口，完全无需变更IP地址。

   

网络特权容器：除了容器的典型用途外，在一些特殊情况下，运营商希望使用主机IP地址直接公开容器化服务（例如，HAProxy[8]、OpenVPN[28]和MemSQL[30]）。在这种情况下，通过与容器共享主机命名空间，容器可以访问主机网络接口，并直接公开其服务。在本文中，我们将这种情况称为网络特权容器。

容器网络挑战

1. 容器上下文丢失：当创建一个Docker容器时，同时会创建一对vet pair接口，这对接口一端在容器内，即eth0，另一端在本地被挂载到docker0网桥，名称以veth开头，eth0只在容器内可见。一个安全相关的问题是，容器生成的每个包在转换到主机网络名称空间时将失去与源容器的关联，这意味着数据包已经流入容器网络。这时，任何根据安全检查（源地址校验和网络流控制）的决策以及数据包转发仅仅依据数据包的头部信息，对于一个受到攻击的容器完全可以伪造数据包从而进行横向攻击或者网络流投毒。

2. 基于IP的访问控制的局限性：在容器平台之间实施网络流量控制的主要方法是通过iptables，一种由Linux内核提供的基于IP的访问控制。但是，容器的IP地址可以是动态的，每当容器创建或者销毁时都需要进行调整。因此，从性能和安全性两方面为容器指定安全策略可能是一个挑战，因为每当重新创建容器时，必须更新这些策略，并且在策略更新期间也应锁定iptables的策略表。此外，尽管运营商实施了各种安全策略，但由于iptables的范围有限，容器网络仍然容易受到数据链路层攻击，如ARP欺骗、DHCP攻击、MAC洪泛攻击等。

3. 网络策略爆炸：细粒度的网络控制需要更大的网络策略集，此外，由于每个容器可能需要不同的策略，策略的总体数量将随着容器生态系统的异构性和大小而增加。iptables管理着主机上所有网络接口上的网络规则，导致网络策略难以管理甚至发生网络策略爆炸（随着大量容器的部署，网络安全策略的数量急剧增加）。因此，如果iptables中的安全策略数量增加到数百个以上，容器生态系统可能会面临显著的性能下降[37]。

4. 不受限制的主机访问：每个容器网络都有一个用于外部访问的网关接口，即上图中网桥连接着的GW。由于容器可以访问在主机端启动的服务，因此会产生固有的安全问题。在Kubernetes中，容器甚至可以通过分配给它们的网关IP地址访问所有其他主机（节点）。如果在主机中运行的服务打开了某个网络端口，如图3所示，容器可以通过网关IP地址直接访问该服务。在最坏的情况下，恶意容器可以以破坏/损害主机可用性的方式利用服务。

   

5. 没有对网络特权容器进行限制：尽管网络特权容器（network-privileged container）因为网络流不经过额外的网络栈（如容器网络）会有性能上的优势，但是也会引起操作隔离方面的问题。网络特权容器不仅可以访问主机网络接口，还可以监视主机上所部署的容器的所有网络流量且不受限制地将恶意数据包注入容器网络。此外，当前的安全解决方案没有考虑此类容器的安全策略；因此，运营商必须自行为容器设计和指定安全策略配置。

   

假设和威胁模型

假设攻击者有足够的能力通过网络可访问的容器应用程序（作为微服务的一部分）进行远程劫持，使其能够在远程被攻击容器内的shell中执行任意命令。

威胁模型考虑的范围着重于通过被劫持的容器发起基于网络的横向攻击，而非可能发生在容器内部的系统层面的攻击，因为当前已经有大量的工作对其进行了探索，并且我们相信运营商在部署容器时采用了系统层面的安全策略。在这里，一个特定的攻击案例是，受到攻击的容器正常运行，发起横向攻击并不需要在容器内提权，攻击者可以通过查看一些系统文件（如/proc/net/arp /proc/net/route）来获取容器网络的配置情况。

容器网络接口插件的限制

BASTION作为一种透明的容器网络安全扩展可以有效应对上述讨论的安全挑战。不同于当前存在的依赖于运营商自定义网络策略来保护容器免受各种网络攻击威胁的容器网络接口插件，BASTION能够自动地从容器平台发现容器间的依赖关系，并提供智能的容器感知的通信沙箱来保护容器间的通信（an intelligent container-aware communication sandbox）。

BASTION设计

BASTION设计考虑了以下几点：

1. R1容器感知最小特权通信实施（Container-aware least privilege communications enforcement）：容器的连通性应取决于其自身与那些需要通信才能构成服务的容器之间的相互依赖性。
2. R2可伸缩和细粒度的网络策略表示：容器网络中的网络策略表达和执行性能应该很好地适应现代主机容器拓扑的动态性和规模。
3. R3对容器内通信的策略控制：虽然网关接口在与外部网络的通信中起着关键作用，但网络栈应过滤掉网关接口的直接访问，以防止滥用主机命名空间。
4. R4网络特权容器的策略实施：网络策略实施应该能够对启用了网络特权的容器进行细粒度的访问控制，这些容器共享用于直接访问主机接口的主机网络名称空间。
5. R5未经授权的窃听和防欺骗。通信中介应防止访问第三方数据包（即窃听）和生成虚假数据包（即防止ARP欺骗和本地容器之间的流量注入）。
6. R6具有竞争力的性能，可与任何容器拓扑进行很好的扩展。网络栈应该提供低延迟和高吞吐量的通信，同时保障容器网络安全性。

BASTION架构图如下所示：

当数据包到达BASTION网络栈，网络可见性服务按照容器网络图（Container Network Map）处理ARP请求，从而主动过滤掉与当前容器不相关的容器的发现进程（R1,R5）, 并根据容器间依赖图（Inter-container Dependency Map）指定的安全策略对容器之间的通信作限制（R1）。此外，一个特殊的IP处理程序对未授权的对特定IP地址(如网关IP地址)访问进行限制（R3）。流量可见性服务则进行容器间的安全数据包转发，该服务首先基于容器身份验证该数据包(R4-5)，然后基于其接口信息将数据包从源容器直接传递到目标容器（R6）。因为数据包的直接传递是在网络接口层次上（主机侧），消除了未授权的网络流量监听的可能性(R4-5)。

对于跨主机的容器间通信，一个特定的BASTION网络栈运行在每个节点的外部接口，它只保留该节点上部署的所有容器的容器网络图，因为所有的安全决策都是在容器内部的BASTION网络栈进行的。因此，当该BASTION网络栈接收到来自其他节点的数据包，它仅仅将该数据包从外部接口安全转发至目标容器。主机间的通信使用现有的覆盖网络，BASTION还保留了容器平台的现有机制来处理来自外部网络的入站流量。

BASTION MANAGER

BASTION Manager扮演两个主要的角色，一是从容器平台收集所有活跃容器的网络信息，二是管理部署在活跃容器内的BASTION网络栈。

容器信息收集

BASTION Manager(下面用bm替代)维护2个哈希表，即针对所有容器的容器网络表（Container Network Map）和容器间依赖表(Inter-container Dependency Map)。如上图所示，bm基于容器平台获取所有容器的网络信息，基于获取到的网络信息和出入口安全策略提取容器间的依赖关系并建立容器间依赖表。此外，由于容器会动态地产生或者销毁，bm以轮询的方式阶段性地获取容器网络信息从而更新上述哈希表，轮询的方式能够保证兼容性和透明性（无需任何修改即可与已部署的容器环境整合）。

• 自动提取容器间依赖关系：bm能够自动提取容器间的依赖关系，为了实现这一点，首先定义一个容器网络模型，在该模型中，一个微服务由一个或多个容器集合(Container Set)组成，一个容器集合又由具有相同功能的一个或多个容器组成（由于扩展或者负载均衡）。每个容器集合通过内部的服务端口和其他容器集合通信，而微服务通过全局的服务端口将外界的访问请求转发到对应的内部服务端口上。然后，我们为容器间通信中的隐式依赖关系定义了四个约束条件，

  1. 相同容器集合内部的容器不连通；
  2. 不同容器集中的容器仅通过内部服务端口进行通信；（配置明确公开）
  3. 彼此间不相关的容器可以通过全局服务端口进行通信；
  4. 默认情况下不允许所有其他通信；

  基于上面定义的容器网络模型，所有的容器间依赖关系可以用算法1进行提取。

  算法1：对于活跃的容器集合的任何两个容器u和v，如果u和v之间存在显式依赖关系（不同容器集中容器通过内部服务端口通信），$p_{uv}$为u的出口安全策略和v的入口安全策略的交集（入口策略和出口策略很好理解，比如对于内核中的网络接口，通过iptables可以为该接口指定一条规则允许具有特定源IP地址和目的IP地址的数据包通过，如形式为srcIP:port destIP:port allow），然后将v加入到容器u的容器间依赖关系表中，策略为$p_{uv}$；如果u和v之间不存在显示依赖关系，且u和v不属于同一个容器集合（u和v是不同微服务中的容器），则将u的所有出口策略中目的地址为v所在微服务的全局服务端口的策略加入到u的容器间依赖关系表中；最后，将从u到所有微服务IP地址及端口的策略加入到容器间依赖关系表。

  

• 维护容器间依赖关系表中策略：在容器间通信流量控制过程中，BASTION Manager产生网络日志来记录目的或者源为ContainerID的网络访问，然后将其与所维护的容器间依赖关系表进行比较，并将该访问划为三种：合法的访问，策略丢失(missing policies)，过度策略(excessive policies)。如果观测到的容器间的通信不在容器间依赖关系表中，bm认为需要补充策略或者认定该访问无效，然后通知运营者决定是否需要在容器间依赖关系表中新增对应的安全策略。除此之外，bm还识别依赖关系表中多余的策略，即并没有遇到对应的网络流量，在这种情况下，通知运营者检查可能需要在当前配置中更新的策略。

BASTION网络栈管理

BASTION Manager为每个容器维护BASTION网络栈，对于每个新产生的容器，bm在容器内部网络接口上安装BASTION网络栈以及对应的容器网络表和容器间依赖关系表。关于表的大小，每个容器仅需要全局哈希表的一部分来和具有依赖关系的容器进行通信，因此bm对于无关的信息进行过滤，同时bm监测容器间依赖关系的变化并自动更新对应容器网络栈中的哈希表。

Network Visibility Service

网络可见性服务对容器间、容器与外部主机的不必要的通信进行限制。为了实现这一点，下面将要介绍的三个安全组件分别用来处理容器发现、容器间通信和网关/服务IP地址访问。

Direct ARP Handler

对于容器间的网络通信，容器发现（container discovery）是第一步，即通过ARP请求来获取关于目标容器必要的网络信息（如MAC地址），由于当前网络栈不对ARP扫描进行阻止，因此恶意的容器发现进程可以扫描连接到同一网络中的所有容器。而BASTION网络栈中的Direct ARP Handler组件能过过滤掉非必须的容器发现的ARP请求包，即该通信不符合当前容器的依赖关系表所定义的网络安全策略。具体过程为，当一个容器发送给ARP请求之后，处理程序在其广播之前拦截该请求数据包，并验证依赖关系表中是否存在Source为ARP请求的源IP对应的容器、Destination为ARP请求的目的IP对应的容器的策略：如果可以访问，处理程序根据容器网络表（Container Network Map）生成一个ARP应答数据包并将其发送给源容器（并没有ARP请求流入到容器网络）；否则，丢掉该ARP请求。

Inter-container Communication Handler

Direct ARP Handler不能解决具有依赖关系的容器间的恶意访问，因为为了进一步限制容器的可达性，第二个组件实现了容器感知的网络隔离。

如上图，BASTION网络栈网络可见性服务中的Inter-container Communication Handler组件拦截到从WebApp对应容器发出的数据包，并获取到目的容器的IP地址，然后将其作为键查找哈希表（容器间依赖关系表），如果查找到了对应的策略，检查数据包是否符合该策略，符合则转发该数据包到下一个组件，否则丢弃。

BASTION实现了每个容器的规则分区策略，这简化了规则冲突评估，因为在容器部署和规则冲突评估时仅仅考虑与当前容器相关的规则。此外，相比于Iptables集中管理所在主机所有容器的网络安全策略，BASTION网络栈仅维护当前容器相关的网络策略，这种方式带来了显著的性能提升。随着容器数量的增加，与主机全局网络策略规则实施相比，此方法具有固有的关键优势。用于管理大量全局（主机层）网络安全规则集的常见策略是应用全局规则优化算法（例如，将规则聚合为简化集合）。不幸的是，由于容器是动态上下旋转的，特别是在大型协调的容器生态系统内，它们相应的安全规则也将需要频繁更新。在这种情况下，全局规则优化可能会证明效果不佳，甚至会成为我们规则划分策略的新性能瓶颈。

Gateway and Service-IP Handler

在容器环境中，被攻击的容器可能利用网关来刺探主机操作系统对外提供的服务。为了解决这个问题，BASTION网络栈中的网关IP处理程序对直接的主机访问进行过滤。正常而言，当一个容器网络连接目的地址不是本地容器地址时，网络数据包通常包含网关的MAC地址和其他主机目的容器的实际IP地址。根据这一事实，处理程序可以检查数据包中的目的IP地址和目的MAC地址是否都属于网关，网络流也可能访问其他容器网络的网关，因为这些网关也连接到主机网络， 因此，网关IP处理程序还通过将数据包与其他网关进行比较来过滤未经授权的主机访问。

在Kubernetes环境中，有一类特殊的IP地址Service Cluster IP（虚拟IP地址）, 它的作用是将Service访问重定向到实际的容器，由于此类IP不属于容器网络，因此可以将其看作是外部IP地址。因此BASTION从k8s提取出{service IP address, port}和{corresponding container IP address, port}并在每个容器的BASTION网络栈维护一个对应的服务映射表。当一个容器发送带有Service IP地址及端口的数据包，Service-IP处理程序将其改写为对应的容器IP地址和端口。

Kubernetes之Service

Kubernetes中的PodIP、ClusterIP和外部IP

Service是一组逻辑pod的抽象，为一组pod提供统一入口，用户只需与service打交道，service提供DNS解析名称，负责追踪pod动态变化并更新转发表，通过负载均衡算法最终将流量转发到后端的pod。

在创建Service时，工作过程如下：

1. 为实例分配置集群虚拟IP。如果在声明时明确指定集群虚拟IP，则分配指定IP，如未指定则自动分配。
2. 根据实例名称、分配的集群虚拟IP、端口号创建DNS条目。
3. 根据标签选择器聚合符合条件的节点，并创建相应endpoint，endpoint包含所有符合条件pod的ip地址与端口号。
4. kube-proxy运行在集群中每一个节点上，并持续监控集群中service、endpoint变更，根据监控结果设置转发规则，将一个集群虚拟IP、端口与一个或者多个pod的IP、端口映射起来。
5. 当在集群内部通过服务名称访问创建的service时，首先由DNS将服务名称转换成集群虚拟IP与端口号，kube-proxy根据转发规则对service的流量计算负载均衡、转发到位于后端的pod。

当proxy发现一个新的service后，它会在本地节点打开一个任意端口，建相应的iptables规则，重定向服务的IP和port到这个新建的端口，开始接受到达这个服务的连接。当一个客户端访问这个service时，这些iptable规则就开始起作用，客户端的流量被重定向到kube-proxy为这个service打开的端口上，kube-proxy随机选择一个后端pod来服务客户。

Traffic Visibility Service

流量可见性服务保证点到点的容器网络通信的完整性和机密性。BASTION网络栈通过两个安全组件source vertification和end-to-end direct forwarding来隐藏与容器不想关的通信流量。

Source Vertification

为了精确地跟踪容器间流量的实际来源，BASTION网络栈利用传入数据包的内核元数据（比如入口网络接口索引）。每个BASTION网络栈静态地包含对应容器的网络信息（IP/MAC地址 容器侧、主机侧网络接口的元数据），BASTION不仅对传入数据包的头文件信息进行校验，还能将数据包的元数据与网络栈存储的容器网络信息比较从而进行源校验。只要有一个是不相符合的，就丢弃该数据包。

End-to-End Direct Forwarding

当前的网络栈因为对网络流量的过滤是在网络流量捕获之前进行的，因此不可避免的会存在流量被监听的风险。如果一个恶意的容器能够将目标容器的网络流量重定向到自己的端口，将能进行无限制的监听。而对于网络特权容器，整个容器网络对它都是可见的，并不需要对流量进行重定向。

为了保证容器网络流量的机密性和完整性，BASTION实现了端到端直接转发组件，使得容器间网络流量不仅绕过容器侧的原始的网络栈，还绕过了主机侧的网桥，因此可以有效避免其他对等容器的网络窃听。

一旦BASTION网络栈接收到来自其他容器的网络流量，它从容器网络表（Container Network Map）获取该容器的接口信息：如果它们在同一个节点上，直接通过端到端直接转发组件将流量发送到目标容器；否则将流量发送到目标容器所在主机的外部接口的BASTION网络栈，然后再直接转发给目标容器。

实现

基于Linux 4.16，实现了两个子系统：BASTION Manager和BASTION网络栈，包含2200行C代码和5100行python代码。

1. BASTION Manager：对于容器信息收集，该组件定期从Docker引擎和Kubernetes API Server获取活跃容器的属性信息（如网络配置）。特别地，它通过特殊的关键词（“link” “depends_on”）获取显式的容器间依赖关系，对于k8s，无法显示确定容器间依赖关系，使用标签信息来发现（比如标签：“dipendencies: containerA”）。对于网络安全策略，从主机和k8s的iptables组件中提取出入口网络安全策略。
2. BASTION Network Stack：基于eBPF和XDP实现。

评估

安全性评估

攻击场景：Kubernetes容器环境下

• 服务：分别为合法用户和游客提供Nginx、Redis服务，服务运行在容器中，镜像来自Docker Hub；
• 攻击结果：攻击者通过web漏洞获得Nginx(Guest)容器的控制权，在容器网络中进行中间人攻击；
• 攻击链：ARP扫描发现容器网络所有活跃容器信息，发送ARP应答报文欺骗Nginx(User)将正常发送给Redis(User)的网络流量重定向到Nginx(Guest)，伪造应带数据包；

BASTION安全性评估结果：

• 容器发现过程：direct ARP Handler组件和container-aware network isolation组件只允许当前容器探测到与其有依赖关系的容器的网络信息，即图中的网关和Redis(Guest)。

  

• 网络流量监听：流量可见性服务中的端到端直接转发组件能够有效避免容器对目标容器的流量窃听，上图是未开启端到端直接转发组件，可以看到能够监听到目标容器的所有网络流量；下图是开启了端到端直接转发组件（为了更具对比性，对于从源容器到目标容器的流量不开启端到端直接转发，反向则开启），可以看到监听不到从目标容器到源容器的网络流量。

  

• 主动数据包注入：关闭ARP处理程序，允许容器发送ARP应答程序，A是不开启源校验组件，可以看到A成功向Nginx(User)发送了RST数据包从而成功中断当前会话，B是开启源校验组件，可以看到Nginx(Guest)尽管向Nginx-User发送了RST数据包，当Nginx-User所在容器的BASTION网络栈的源校验组件丢弃了该RST数据包，注入失败。

  

性能评估

• BASTION网络栈部署开销：平均13.03微秒

• BASTION与iptables安全策略检查开销对比：BASTION对于TCP数据包的吞吐量更高；随着安全策略的增加，iptables的吞吐量下降，BASTION稳定，这是因为BASTION的安全策略检查是在各个容器内部进行的，与当前容器相关的安全策略有限且基于哈希表查找。

  

• 单一主机部署性能：BASE采取容器的默认配置且无安全服务；NVSvc采用网络可见性服务，TCP和UDP延迟提升5.7和9.3个百分点；TVSvc采用流量可见性服务，TCP和UDP延迟大概下降了26.3个百分点，因为在流量可见性服务中使用端到端直接转发组件，绕过了容器已有的网络栈；BASTION采用所有的安全服务TCP和UDP延迟分别下降了23.0和25.4个百分点。

  

• 跨主机部署性能：由于跨主机的物理链路开销和隧道开销，其延迟是要高于单主机间容器通信；BASE方式TCP和UDP延迟分别为100.1微妙和91.5微妙；NVSvc方式开销升高不足1一个百分点；TVSvc方式开销平均下降21.3个百分点；BASTION方式开销平均下降17.7个百分点。使得跨主机容器间通信吞吐量提升了12.9个百分点。

  

  

• 基于不同网络插件部署性能表现：

  

总结

分析了当前容器网络的安全性，提出了BASTION来解决现有的安全风险挑战，能够有效解决现存的安全问题且有显著的性能提升。