这是两篇译文，冬至放出。本篇来自顶级开源身份和访问管理软件厂商wso2，揭示内部研发平台如何培育零信任及可观察性。比较另类，技术难度高，选择性阅读，似乎揭示出不一样的身份安全场景。【中途有新闻插播】

"即将出版的O'Reilly新书《软件开发的身份安全》的作者最近将以实用可行的方式探讨基本的身份安全概念，尽请留意。"

作者：Lakmal Warusawithana云架构高级总监-WSO2

零信任安全背景下的可观察性

过去，企业软件侧重于通过本地防火墙和 VPN 保护网络访问，并假设网络内的所有内容都是安全的。然而，如今，随着数据访问已从本地位置扩展到云和混合网络，SaaS 平台需要一个能够解决更广泛攻击媒介的安全模型。零信任安全解决了这一迫切需求。它遵循以下基本原则：

·永远不要相信，永远验证

·明确验证

·最低权限访问

·微分段

·分层安全控制和MFA

·假设违规

·端到端加密

·用户和系统的完整可见性

然而，零信任不仅仅是一个附加功能，它需要针对平台的每一层采用全面的架构方法。每个组件、连接和数据流都应符合上述八项原则中的一项或多项。

在本文中探索在Choreo（我们的内部开发人员平台即服务）中实现和培育零信任安全的旅程。我们将分析必要的架构调整，并了解如何将零信任融入 Choreo，以确保坚固且有弹性的安全防护。

Choreo: 鸟瞰图

在 Choreo 中，架构分为两个基本组件：控制平面和数据平面。控制平面承担管理组织、用户和项目的基本任务。此外，它还管理应用程序开发的整个过程，从创建的初始阶段开始，一直到部署，纳入治理措施，最后提供可观察性。Choreo 控制平面迎合各种用户角色，包括 CIO、架构师、开发人员和 DevOps/SRE/PE，通过Asgardeo和审核日志支持的多重身份验证 (MFA) 确保所有用户登录的强大安全性，以避免任何用户登录不可否认的情况。

数据平面是部署用户应用程序的地方，由控制平面中建立的设置引导。用户应用程序可以包括按定义的时间表运行的服务、Web应用程序和任务。这些应用程序可以用任何编程语言编写，支持多语言方法。值得注意的是，与用户应用程序运行时相关的所有流量都限制在Choreo数据平面的边界内。这确保了用户数据严格保留在数据平面内，并且永远不会超出其限制。为了了解Choreo 如何保护数据，我们有深入的文档，深入探讨了数据处理过程的细微差别。

Choreo的架构具有两种不同类型的数据平面：云数据平面和私有数据平面。云数据平面利用多租户基础设施模型来部署用户应用程序，为应用程序运行时提供公共且安全的环境。相比之下，私有数据平面提供分配给单个组织用于运行其用户应用程序的专用基础设施。这可以确保为具有特定要求的组织提供额外的隐私和控制层。

图 1：Choreo 鸟瞰图

无论数据平面类型如何，Choreo 都会在两者之间强制执行零信任安全模型。这种方法可确保每个应用程序（无论是在共享云数据平面上还是在专用私有数据平面上运行）都能从零信任模型中受益。这种安全策略的一致性是我们为所有用户创建安全、可靠和强大平台的承诺的一部分。

用于微分段的基于单元的架构

Choreo在基于单元的架构上运行，这种方法将设计、实现和部署的组件分组到一个称为“单元”的统一实体中。这些单元作为平台的基本构建块，每个单元都可以独立部署、管理和观察。单元直接对应于 Choreo 项目，并体现了基于单元的架构中讨论的属性。

在每个单元内，组件使用支持的单元内通信传输方式相互通信。这种本地化通信可优化性能并最大限度地减少延迟，从而确保单元范围内的交互安全。

但是，任何外部通信都必须通过 API 网关。这一关键的架构功能充当受监管的入口点，使用标准网络协议通过受管网络端点提供 API、事件或流。该网关确保所有传入和传出流量都受到严格监控和管理，从而与“从不信任，始终验证”很好地保持一致。

图 2：电信术语中的蜂窝通信

具有Cilium和eBPF的基于Choreo Cell的架构

在 Choreo 数据平面中，两个API网关发挥着重要作用，管理针对用户应用程序的内部和外部流量。第一个网关促进源自公共互联网的外部 API 流量到达项目中运行的用户应用程序。第二个网关路由来自其他项目组件的内部流量，这些组件虽然源自同一组织内部，但属于特定 Choreo 项目的外部。

每个 Choreo 项目都由不同的组件（例如微服务、集成、Web 应用程序和任务）组成，并捆绑并部署到不同的 Kubernetes 命名空间中。这个专用命名空间对于特定环境中的每个项目都是唯一的，构成了 Choreo 基于单元的架构的重要元素。

Cilium是一个针对云原生环境的开源解决方案，利用eBPF（一种先进的内核技术）在工作负载之间提供安全且可观察的网络连接。我们利用跨OSI网络模型第 3、4 和 7 层运行的Cilium策略来管理Choreo数据平面内的入口和出口流量。这种多层策略应用程序提供了更大的灵活性和对数据平面内网络流量的控制。

通过采用 Cilium 网络策略，我们确保了这些项目命名空间的安全。这将限制在项目名称空间之外运行的任何工作负载访问其内部组件，符合网络第3层和第4层已建立的Pod标签和基于身份的网络安全策略实施。允许进入项目的唯一流量是路由的流量通过内部和外部网关。两个网关都保持严格的控制，仅允许通过 Choreo 的API管理功能专门策划和发布的 API 访问组件资源。这些托管 API 通过巧妙地使用范围绑定和基于角色的访问控制 (RBAC)来实现细粒度的访问控制。这种精细的授权机制可确保特定权限得到适当分配和验证，从而增强整体安全架构。通过这种架构和策略实施，从项目外部对组件内的资源的任何访问仅在成功的身份验证和授权后发生。

Choreo确保所有内部网络流量都经过加密，这是我们通过使用Cilium透明加密实现的功能。此方法利用内核内IPsec提供高效的数据路径加密，这在云数据平面内特别有用。鉴于需要传输保护的数据的敏感性，这种加密策略至关重要。Cilium透明加密的独特优势在于其内核级操作。这一独特的功能使其在性能方面比用户空间解决方案具有显着优势。

图 3：Choreo 项目信任边界

除了上述策略执行之外，我们正在推出基于Cilium附带的身份验证支持的细粒度访问控制策略。

Choreo的一个显着优势是它专注于应用程序开发治理。在构建应用程序的过程中，可能需要与外部端点进行交互。但是，由于公司政策、业务敏感性或数据的关键性，可能有必要将交互限制为仅与批准的端点进行交互。Choreo 将在项目设计期间通过可视化图表确保这种级别的治理。

当应用程序架构或开发人员建立这些治理要求时，Choreo可以有效地将它们转换为基于Cilium DNS的网络策略。这些策略提供了一种指定访问控制的机制，而Cilium负责跟踪DNS到IP映射的更复杂的任务。

图 4：使用基于DNS的网络策略控制出口

未来，除了简单地控制外部出口之外，Choreo的治理框架还将确保严格控制项目内组件之间的未经授权的访问。当此类交互未在合同中定义（例如，开放 API 规范）或架构师或开发人员在组件设计阶段未设想时，这一点尤其重要。

Choreo将这些设计原则转化为Cilium L7网络策略。这些策略强制执行资源级授权以及组件标签（在部署到POD时分配），这些标签使用eBPF合并到网络通信中。要更详细地了解这个过程，可以参考《利用eBPF解锁Kubernetes中可编程数据平面的强大功能》。【转到本文第二章节】

图5：资源级授权的L7策略

这种控制级别进一步强调了Choreo对零信任安全模型的承诺。即使交互源自项目内的组件（否则可能被认为是相当可信的），这也是如此。这种访问控制的粒度增强了我们平台的安全性，确保为用户的应用程序提供强大而可靠的环境。

降低容器逃逸风险

Choreo 使开发人员能够灵活地使用各种编程语言构建应用程序。这些应用程序随后通过 Choreo CI/CD 管道编译并打包到 Docker 容器中，并部署到运行时 Kubernetes 集群中。Choreo CI/CD 管道旨在确保所有构建的 Docker 映像都符合Choreo 的安全准则。

Choreo 通过为平台内每个用户应用程序的容器部署分配不同的身份来进一步增强其防御能力。这些身份经历了对其交互的持续验证和验证过程，我们之前讨论过这一点。在这种模型下，即使攻击者设法利用漏洞并执行容器逃逸，他们的旅程也不会就此结束。他们仍然需要通过后续的授权检查才能访问主机或其他容器上的资源。这种多层验证过程充当了额外的防线，使潜在攻击者破坏我们的系统变得更具挑战性。

零信任安全背景下的可观察性

请记住，零信任不仅仅在于防止未经授权的访问，还在于能够识别何时出现问题并做出适当的响应。这就是安全可观察性发挥作用的地方，它提供确保系统安全所需的见解和理解。

Choreo 中项目级别的可观测性提供了一个动态服务图，它可以可视化 Cilium 利用 eBPF 的功能捕获的所有网络活动。该服务图是根据项目规划期间制定的设计时定义验证所有运行时网络活动的重要工具。

运行时服务图中出现的意外网络调用可以作为潜在恶意活动的预警。这种实时验证功能可确保运行时行为符合初始设计原则，是 Choreo 中实现的零信任安全模型的一个重要功能。通过持续观察和实时调整，Choreo 提供了一个安全的环境，促进对项目规范的遵守，同时有效防止未经授权或意外的操作。

图6：Choreo项目服务图

Choreo 坚持全面的日志记录策略，捕获多个级别的每一个操作。无论是应用程序、API 网关、Kubernetes 事件、访问日志、入口日志还是审核日志，所有这些都会被认真跟踪和存储。这些审核日志记录每次访问尝试及其细节（谁访问了什么以及何时访问）。

在我们寻求维护零信任安全模型的过程中，我们认识到对安全数据进行全面和智能分析的重要性。为了实现这一目标，安全信息和事件管理 (SIEM) 系统至关重要。Choreo 与 Azure Sentinel 等高级 SIEM 解决方案集成，使我们能够收集、聚合和分析整个平台的安全数据。

借助 SIEM，我们可以关联来自不同来源的数据，例如应用程序日志、API 网关、Kubernetes 事件、访问日志、入口级别日志和审核日志，从而增强我们实时识别模式、检测异常和响应潜在威胁的能力。这种深入的分析支持我们“永不信任，始终验证”的方法，使我们能够持续监控和验证平台上的活动。

图 7：私有数据平面安全架构（在Azure中）

图 7 概述了我们如何在 Azure 中运行的私有数据平面上战略性地实施各种安全控制。这些控制措施旨在解决我们平台运营的各个方面。我们在AWS和GCP 云上为私有数据平面实施了类似的安全控制器。

例如，我们的控制涵盖了用户应用程序的运行时环境，确保所有正在运行的应用程序都遵守零信任模型建立的严格安全协议。此外，我们的安全控制扩展到站点可靠性工程 (SRE) 操作领域。它们在维护活动期间充当坚定的守护者，确保即使在系统升级或故障排除活动期间也能保持操作完整性。

从本质上讲，我们的分层安全方法（如图7所示）可确保我们平台的每个方面都受到持续的安全审查。

零信任和合规性

在Choreo中实施零信任安全模型显着增强了我们的SOC2合规状况。值得注意的是，WSO2目前拥有SOC2 Type1 认证，我们正在努力获得Type2认证。

零信任模型的核心原则，包括多层身份验证、最小权限访问、加密以及永久日志记录和监控，符合SOC2审计的严格操作和安全控制要求。

通过坚持零信任模型，我们不仅加强了平台的防御机制，还提高了我们的运营完整性，这以我们的 SOC2 合规性为基础。这确保了我们客户的应用程序受到优先考虑安全可靠性和严格遵守行业标准的平台的保护。

概括

以下要点总结了 Choreo 对零信任安全原则的应用，并展示了它们如何融入平台中：

·永不信任，始终验证： Choreo 通过多层安全控制体现了这一点：身份验证和授权验证实体的合法性，API网关规范对资源的访问。持续监控、全面的日志记录以及与Azure Sentinel的集成有助于实时行为跟踪和异常检测。

·显式验证： Choreo 通过使用API网关来调节外部和内部流量来实现此目的，确保每个访问请求都经过身份验证和授权。

·最小权限访问：嵌入在架构中，通过基于角色的API授权、基于用户定义的连接规范的细粒度访问控制以及对网关访问的严格控制来实现。

·微分段：平台采用基于单元的架构，将每个项目部署在不同的Kubernetes命名空间中，有效创建具有独立部署和隔离通信范围的微分段。

·分层安全控制： Choreo应用多层安全控制，例如通过Cilium网络策略实施网络级控制，以及实施由Asgardeo提供支持的MFA

·假设违规： Choreo在潜在违规的假设下运行，并强调使用Azure Sentinel 进行实时网络可观察性、全面日志记录和异常检测的必要性。这使得平台能够及时识别并响应潜在威胁。

·端到端加密：该平台通过Cilium透明加密确保端到端加密，提供高效的数据路径加密。

·完整的用户和系统可见性： Choreo提供全面的日志记录策略，捕获多个级别的活动，包括应用程序活动、API 网关、Kubernetes 事件、访问日志、入口日志和审核日志。它还在项目级别采用可观察性来可视化所有网络活动，强化“永不信任，始终验证”的原则。

新闻插播

2023年12月21日，思科宣布收购 eBPF 的主要贡献者 Isovalent 公司！
Isovalent 团队是开源技术 eBPF 的主要贡献者，并领导了 Cilium 的开发，Cilium 是领先的网络和安全云原生解决方案。
“与Isovalent合作，思科将借助Cilium的开源力量，打造一种真正独特的多云安全和网络能力，帮助客户简化和加速数字化转型之旅，”思科安全与协作执行副总裁兼总经理Jeetu Patel表示。“想象一下，在当今分布式环境中，应用程序、虚拟机、容器和云资产都具备完全可见性的安全控制，而不会影响网络和应用程序的性能。思科和Isovalent的结合将使这成为现实。”

使用 eBPF 释放 Kubernetes 中可编程数据平面的强大功能

可编程数据平面为云原生应用程序提供动态控制。eBPF和Kubernetes等技术提供了一种抽象来提高灵活性、可扩展性和性能。阅读本文，了解如何将可编程数据平面与eBPF结合使用。

随着当今快节奏的数字世界对云原生应用程序的需求不断增长，传统数据平面必须发展为可编程数据平面，以满足不断变化的需求。传统数据平面通常依赖于专有硬件，这限制了灵活性、可扩展性和创新。这阻碍了他们满足云原生应用程序不断变化的需求的能力，导致性能、可靠性和安全性下降。相比之下，可编程数据平面提供对网络行为的动态控制和操作，使其成为云原生应用程序的理想选择。它们可用于使用商用硬件构建经济高效且可扩展的网络基础设施，并提供与更昂贵的专有硬件解决方案相同水平的性能、可靠性和安全性。

软件定义网络 (SDN)、网络功能虚拟化 (NFV) 和扩展伯克利数据包过滤器 (eBPF)等较低级别的网络技术当然可以在创建可编程数据平面方面发挥作用。近年来，eBPF尤其受到广泛关注，因为它能够在Linux内核中提供低开销、高性能的网络处理。

Kubernetes是一个开源容器编排系统，可自动执行容器化应用程序的部署、扩展和管理。它提供了一个以云原生方式部署基于微服务的应用程序的平台，其中每个服务都可以独立部署、扩展和更新，而不会影响其他服务。另一方面，服务网格是一个基础设施层，它提供对微服务如何相互通信的细粒度控制。它为基于微服务的应用程序添加了流量路由、负载平衡、服务发现和可观察性等功能。服务网格通常通过在每个微服务旁边部署sidecar代理来工作，该代理拦截并路由网络流量。

Kubernetes 和服务网格平台可以为创建可编程数据平面提供更高级别的抽象。这两个平台都抽象了微服务之间的网络通信，并提供API和库来通过不同的网络策略管理网络通信。这种抽象简化了可编程数据平面的实现，并利用eBPF 等可编程网络技术来提供对网络行为的精确控制。本文重点介绍eBPF在结合 Kubernetes平台创建有效的可编程数据平面方面的作用。然而，值得注意的是，并非所有服务网格都使用eBPF等较低级别的技术。

eBPF

eBPF是一项Linux内核技术，为用户空间程序提供了一种安全高效地与内核交互的方式。用户空间程序是在操作系统内核之外运行的软件程序，并且在称为用户空间的单独内存部分中运行。这些程序的权限较少，并且与操作系统的关键功能隔离，这些功能是为内核空间保留的。它允许将小型内核程序（称为 eBPF 程序图 1 中的 eBPF 框）附加到内核中的各种挂钩，并使用它们来分析和操作网络数据包、系统调用和其他事件。

图 1：eBPF 概览图

eBPF提供了高度的可编程性，并确保加载的程序是安全的，不会导致内核崩溃。eBPF 加载的程序在内核内的受限环境（称为eBPF 沙箱）中执行。沙箱确保程序无法直接访问或修改内核数据结构，只能通过定义良好且更安全的 API 与其进行交互。此外，eBPF 程序在使用即时 (JIT) 编译器加载到内核之前会经过安全性和正确性验证。JIT 编译器将 eBPF 字节码转换为本机机器代码并检查潜在的安全漏洞。如果检测到任何问题，程序将被拒绝，从而阻止其加载到内核中。

图 2：eBPF 程序验证

这种安全级别在稳定性和可靠性至关重要的生产环境中尤其重要。eBPF 的低开销使其非常适合在性能很重要的生产容器环境中使用。

有许多不同的工具可用于编写 eBPF 程序，例如 BCC、Bpftrace和libbpf（如下所示），并且每种工具都有自己的优点和缺点。工具的选择取决于具体的用例和您最熟悉的编程语言。

BPF Compiler Collection (BCC) 提供了一组用于用C和Python创建eBPF 程序的工具和库。BCC附带了一组预构建的工具，可用于监视和调试系统的各个方面。要使用BCC编写自定义eBPF 程序，您可以使用BPF C库或Python 绑定。图 3 展示了BCC提供的一组工具，它构建在eBPF 之上，允许开发人员编写和运行自定义eBPF程序。

图 3：Linux BCC/BPF 跟踪工具

Bpftrace是eBPF的高级跟踪语言，可让您轻松编写复杂的跟踪程序。它提供了创建 eBPF 程序的简单语法，无需编写低级 C 或汇编代码。Bpftrace可用于跟踪系统调用、内核函数和其他事件。

Libbpf是一个用C语言创建eBPF 程序的低级库。它提供了一组帮助函数来简化加载和操作 eBPF 程序的过程。Libbpf可用于为各种用例创建eBPF 程序，包括跟踪、监控和安全性。

一般来说，eBPF用于内核空间中的数据包过滤，但最近，eBPF已扩展到在用户空间中运行，这为在更广泛的用例中使用eBPF开辟了新的可能性。

云原生网络功能

传统数据平面通常依赖基于硬件的网络功能（例如路由器和交换机）来提供路由、防火墙和负载平衡等网络服务。这些功能通常不灵活并且需要专门的硬件来执行。相比之下，可编程数据平面使用基于软件的网络功能，可以对其进行编程以执行各种网络功能。它们可以在商用硬件上运行，从而更轻松地在虚拟化或云环境中部署网络功能。eBPF的使用可以超越网络功能虚拟化的一般实现，并且可以优化网络操作与云原生架构的一致性，如下所示。

服务发现和负载均衡

在 Kubernetes中，服务是一个抽象层，为一组Pod提供稳定的IP地址。创建 Kubernetes服务时，会为其分配一个虚拟IP地址（也称为ClusterIP）和端口号。该 IP 地址是虚拟的，因为它不对应于集群中任何节点上的物理网络接口。相反，它被用作服务的稳定端点，即使各个Pod来来去去也是如此。

当客户端将流量发送到服务的IP 地址和端口时，流量会被称为kube-proxy 的网络代理拦截，该代理在集群中的每个节点上运行。kube-proxy 在每个节点上的本地iptables（或 IPVS）表中维护一组规则，将流量从服务的虚拟 IP 地址重定向到与该服务关联的Pod之一。

图 4：基于网络的负载均衡

kube-proxy 维护一个iptables文件，其中包含其管理的所有服务和端点的所有规则。这可能成为性能瓶颈并导致大规模集群中的可扩展性问题。为了解决基于 iptables 的 kube-proxy 的性能和可扩展性问题，Cilium（一种基于 eBPF 的 Kubernetes 网络和安全解决方案）提供了另一种基于套接字的负载均衡操作模式。在基于套接字的负载均衡模式中，Cilium 创建一个侦听器套接字并将其绑定到服务的 IP 地址。当传入数据包到达时，Cilium 会检查数据包以确定将流量路由到的适当服务端点，然后使用eBPF将数据包重定向到端点的套接字。

图 5：基于socket的负载平衡

基于 eBPF 套接字的负载均衡比基于iptables的kube-proxy 具有更好的性能（见图 6）。使用eBPF可以在内核中进行更高效、更细粒度的数据包处理，从而减少延迟并提高吞吐量。下图显示了基于 iptable的kube-proxy和基于 eBPF套接字的负载均衡之间的一些性能比较。

图 6：kube-proxy (iptables) 和基于 eBPF 的基于套接字的负载均衡器的性能比较

基于身份的网络安全

网络安全非常重要，因为它有助于保护网络上流动的通信和数据免遭未经授权的访问、拦截和修改。基于IP的网络安全依赖于根据分配给网络上设备的IP 地址控制访问。例如，防火墙可能允许或阻止对特定 IP 地址或地址范围的访问。

然而，基于IP的安全性也有局限性，因为IP地址很容易被欺骗或操纵，从而很难确定用户或应用程序的真实身份。这在Kubernetes环境中尤其成问题，因为应用程序高度动态且短暂，IP地址不断变化。

图 7：eBPF 基于身份的安全性

基于eBPF身份的策略可以通过利用eBPF映射中丰富的元数据集来控制来自 Pod的出口调用。元数据包括有关Pod和容器的信息，例如标签和注释，可用于强制执行基于身份的安全策略。此元数据可用于匹配定义允许谁访问哪些服务的策略，并且可以使用加载到内核中的eBPF程序来强制执行这些策略。

例如，当从Pod发送数据包时，eBPF程序可以从数据包中提取Pod元数据，检查是否允许Pod访问服务，然后相应地允许或丢弃该数据包。这提供了一种高度精细的方法来控制对基于身份的服务的访问，而不是依赖于 IP 地址。

除了控制出口流量之外，eBPF还可以在目标Pod上强制执行入口流量策略。当 Pod收到数据包时，eBPF程序可以从数据包中提取元数据并使用它来实施安全策略。例如，程序可以检查数据包是否来自授权来源并且不携带任何恶意负载，然后相应地允许或阻止该数据包。

可观察性

可观察性是通过各种类型的数据（例如指标、日志和跟踪）深入了解系统行为的实践。当前的可观测性实践通常依赖于手动检测，这涉及向系统的特定区域添加代码以收集和分析数据。此过程可能非常繁琐且耗时，并且可能会给希望在其环境中实现可观察性的组织造成进入障碍。

带有sidecar代理的服务网格是在微服务环境中提供可观察性的一种流行方法。sidecar代理可以自动检测应用程序代码并生成遥测数据，这些数据可以由网格控制平面收集和分析，以提供对应用程序行为的可见性。然而，这种方法会带来为每个服务实例运行单独的sidecar代理的开销，这可能会影响性能和资源利用率。

eBPF通过允许内核级检测，提供了一种在服务网格环境中实现可观察性的替代方法。这意味着无需单独的sidecar代理即可收集遥测数据，从而减少开销和资源利用率。eBPF程序可用于捕获网络流量、检查和修改数据包以及生成遥测数据以供集中式可观测平台进行分析。这允许深入了解应用程序行为和底层基础设施，而无需sidecar代理的开销。

Pixie和Hubble是利用eBPF技术在云原生环境中提供更深入的可观测性的工具。

Pixie是一个开源可观察性平台，它使用eBPF自动检测应用程序并收集性能数据，而无需任何手动代码检测。它提供了实时数据处理管道，使用户能够监控其应用程序、解决性能问题并实时分析其数据。Pixie还具有用户友好的界面，允许用户以多种方式可视化其数据，从而轻松了解系统的运行状况。

图 8：Pixie pod 性能火焰图

Pixie基于eBPF的火焰图可以通过提供执行过程中时间花费的可视化表示来帮助识别应用程序代码中的性能问题。火焰图可以识别应用程序代码中的瓶颈，例如占用大量时间的函数或方法，并可以帮助开发人员优化代码以提高性能。此外，Pixie 的火焰图还可以识别与系统资源相关的问题，例如CPU利用率，这可能会影响应用程序性能。

Hubble是一个开源网络可观测工具，它使用eBPF提供 Kubernetes 环境中网络流量的可见性。Hubble 由一个网络可见性守护进程组成，该守护进程在每个节点上运行并使用eBPF收集数据。然后，数据被导出到中央服务器，可以使用 Hubble UI 对其进行分析和可视化。Hubble使用户能够快速识别网络问题，并提供对网络活动的深入可见性，包括数据包级详细信息。

图 9 显示了Hubble的自动服务发现和依赖关系图，它允许操作员可视化 Kubernetes 集群中服务之间的通信流，而无需任何手动配置。

图 9：Hubble 的 Kubernetes 服务依赖关系图

运行时安全

基于eBPF的可观察性提供了一种强大而有效的方法来收集对生产环境中运行的云原生应用程序行为的实时洞察。通过利用eBPF，操作员可以将自定义探针附加到内核，以监视和收集细粒度遥测数据，例如网络流量、系统调用和进程活动。然后可以实时分析这些数据，以检测异常、识别安全威胁并诊断性能问题。

Falco和 Cilium Tetragon是两个流行的开源项目，它们利用基于eBPF的可观察性为云原生应用程序提供运行时安全性。

Falco在用户空间和内核空间中运行，其中系统调用通过使用内核模块或 eBPF 探针进行解释，并使用用户空间中的库进行分析。然后使用配置了 Falco规则的规则引擎过滤可疑事件，并将警报发送到配置的输出，例如系统日志、文件、标准输出等。Falco可用于监控容器化环境，并广泛用于检测和预防云原生基础设施中的安全事件。

Cilium Tetragon 提供了强大的可观察层，可以查看各种系统组件，包括低级内核活动，例如跟踪文件访问、网络活动和功能更改。它将覆盖范围扩展到应用程序层，允许跟踪进程执行、对易受攻击的库的函数调用以及理解 HTTP 请求。Tetragon 还可以检测潜在的安全威胁，例如命名空间逃逸、权限升级、文件系统和数据访问以及使用 HTTP、DNS、TLS 和 TCP 等各种协议的网络活动。此外，它还提供系统调用调用和流程执行的审核以增强安全性。

图 10：Cilium Tetragon 运行时安全性高于深度可观察性

使用可编程数据平面简化开发人员体验：Choreo优势

凭借18年中间件产品创新经验以及为开发人员提供支持的承诺，WSO2 始终优先考虑为业务应用程序开发人员简化复杂性并提高生产力。Choreo是一个内部开发人员平台即服务，利用可编程数据平面的强大功能。通过抽象 Kubernetes 和 eBPF 等复杂技术，Choreo 允许开发人员专注于他们的应用程序，这些应用程序在隐式 API 管理的“单元架构”环境中执行。它提供两种类型的数据平面：Choreo 云数据平面和 Choreo 私有数据平面。

Choreo 云数据平面在多租户基础设施上运行，支持在共享环境中安全部署用户应用程序。它利用 K8s 和eBPF的强大功能，灵活、安全地高效处理网络流量。

另一方面，Choreo 私有数据平面提供专门分配给组织的专用基础设施，确保具有特定要求和合规性需求的应用程序的隐私和控制。

通过 Choreo充分利用可编程数据平面的变革能力。借助由 K8s和eBPF提供支持的 Choreo数据平面，开发人员可以利用前所未有的功能和灵活性。Choreo 使您能够轻松释放应用程序的真正潜力，并以前所未有的方式释放创新。

探索 Choreo 可编程数据平面的功能。

要点

·可编程数据平面对于增强云原生应用程序的网络通信并提供对网络行为（例如流量管理、安全性和可观察性）的精确控制至关重要。

·eBPF是一种高性能技术，可以使代码在Linux内核中高效执行。它可用于实现各种网络功能，包括防火墙规则、流量分析和路由，以提高网络通信的性能、安全性和效率。

·Kubernetes 和服务网格广泛用于构建控制平面和数据平面。这些平台抽象了微服务之间的网络通信，并提供用于管理网络通信的API 和库。这种抽象简化了可编程数据平面的实现，并利用eBPF等可编程网络技术来提供对网络行为的精确控制。

·Cilium是Kubernetes的网络插件，它利用eBPF来替代传统的kube-proxy 组件。eBPF允许Cilium 直接对 Linux 内核进行编程，而不需要 iptables，并执行更高级的负载平衡和网络策略执行功能。

·此外，Cilium 使用eBPF 来实现基于身份的安全性，方法是利用 eBPF 提取工作负载的身份（例如Kubernetes Pod），然后使用该身份来实施安全策略。这种方法使Cilium能够超越传统的基于IP的安全性（依赖 IP 地址来识别工作负载），而是使用更高级别的结构，例如 Kubernetes Pod 和服务身份。

·eBPF 通过允许用户跟踪和分析系统不同层（包括内核、网络和应用程序层）发生的各种事件，在云原生平台中提供深度可观察性。借助 eBPF，用户可以创建自定义探针和跟踪点来收集有关系统调用、网络数据包和其他事件的详细信息，而无需手动检测。

·基于eBPF的运行时安全可以帮助操作员实时检测和响应安全威胁。通过使用 eBPF 检测系统调用、网络流量和其他事件，操作员可以监控系统是否存在可疑行为，并在攻击造成损害之前采取措施进行预防。

·eBPF 是创建可编程数据平面的一项关键技术，因为它可以在 Linux 内核中高效执行代码，以实现防火墙规则、流量分析和路由等网络功能。各种开源项目（例如 Cilium、Pixie 和 Falco）都构建在 eBPF 之上，为创建有效的可编程数据平面提供了不同的解决方案。

·Choreo是一个基于云的平台，利用可编程数据平面来简化应用程序开发。Choreo提供安全、多租户的云数据平面和具有专用基础设施的私有数据平面，强调简单性和生产力。利用Kubernetes和eBPF 等技术，开发人员可以专注于应用程序逻辑，从而轻松实现创新。

来源：https://wso2.com/blogs/

原文始发于微信公众号（安全红蓝紫）：零信任安全背景下的可观察性[译]