Cilium：基于eBPF的高效云原生网络和ServiceMesh方案( 三 ) _ServiceMesh

文章插图
运行时安全性：可观测性和强制实施但容器安全性不仅与网络策略有关，容器运行时也受益于安全策略。Tetragon专注于使用eBPF进行运行时安全可观察性和实施。Tetragon 检测并可以报告一系列安全重要事件，例如：

流程执行事件。
系统调用活动。
I/O 活动，包括网络和文件访问。

文章插图
Tetragon并不是第一个出现的eBPF驱动的安全工具，但它为容器安全带来了许多新功能。如果其他项目在表面上挂接到系统调用，则它们受到检查时间到使用时间漏洞的影响，在该漏洞中，系统调用的参数可能在到达内核之前被覆盖。Cilium 工程师利用他们对内核内部的了解，在不受此问题影响的点上挂钩到事件中。
Tetragon的跟踪策略允许您配置要观察的内核事件，并定义匹配条件并采取行动。更重要的是， Tetragon提供基于Kubernetes身份的上下文信息。例如，如果要检测对特定文件或目录的访问，则可以配置一个 TracingPolicy ，该策略将发出日志，准确告诉您哪个进程（运行哪个可执行文件）、哪个 pod 访问了该文件。您甚至可以将策略配置为在文件访问完成之前终止违规进程。这非常强大，并为容器安全增加了一种全新的方法，以帮助您限制容器暴露的攻击面。像沙赞一样， Tetragon被赋予所罗门的智慧，拥有丰富的知识和对如何采取行动的判断技巧。
Tetragon可以独立使用，独立于Cilium的网络功能。但是想象一下，你可以用一个Tetragon&Cilium超级英雄的团队来做什么，结合网络和运行时安全超能力，这样你就可以，例如，看到启动可疑网络连接的完整进程祖先。

文章插图
无边车服务网格您已经看到 Cilium 不仅实现了 Kubernetes 服务之间的连接，而且还提供了可观测性和安全性功能，并且能够在第 7 层采取行动。这不是与服务网格非常相似吗？是的！现在， Cilium 项目可以提供服务网格功能，而无需将边车注入每个 pod ，从而提高服务网格效率。进步有多大？让我们看一下对同一节点上容器之间的 HTTP 延迟处理的影响。使用 HTTP 代理总是会有成本的，但是，当您使用sidecar模式时，您可能会支付两倍的代价，因为微服务相互通信并且流量同时通过ingress和egress sidecar HTTP 代理。减少网络路径中的代理数量并选择 HTTP filter 的类型会对性能产生重大影响。
下面是一个基准比较，来自一篇深入探讨 Cilium 服务网格如何工作的博客文章，它说明了运行 Cilium Envoy filter（棕色）的单个节点范围的 Envoy 代理与运行 Istio Envoy filter（蓝色）的双边车 Envoy 模型的 HTTP 处理的典型延迟成本。黄色是没有代理且未执行 HTTP 处理的基线延迟。

文章插图
Cilium Service Mesh 通过使用 Envoy 网络代理来实现这种延迟改进，该代理作为 agent 的一部分在每个节点上运行，而不是作为 sidecar 附加到每个 Pod 。但这种改进也不全面的，是因为Cilium在将网络流量重定向到节点范围的Envoy代理之前尽可能多地使用eBPF 。这是一个令人印象深刻的一两拳组合，值得野猫，利用时机和技术而不是蛮力来获得您想要的结果。

文章插图
这不是一种新方法——Envoy 已经在 Cilium 中用于实施第 7 层感知网络策略多年。为了实现其无 sidecar 服务网格， Cilium 扩展了对完全兼容的 Kubernetes 入口和网关 API 实现的支持，以及一个较低级别的 CRD ，该 CRD 在 Cilium 中公开了 Envoy 的全部功能。如果您现在正在使用基于sidecar 的服务网格，并且开始感到与在每个 Pod 中部署服务网格sidecar相关的资源成本紧张，那么现在是将 Cilium Service Mesh 视为资源效率更高的替代品的好时机。