网站的域名和ip地址如何重新解析,2017做网站挣钱,泰州建站免费模板,如何知道网站的字体端午假期#xff0c;我翻译了 OReilly 的报告《什么是 eBPF》#xff0c;其中我觉得第五章「云原生环境中的 eBPF」解答了我心中的很多疑惑#xff0c;比较不错#xff0c;分享给大家。下面是第五章译文。《什么是 eBPF》中文版封面近年来#xff0c;云原生应用已呈指数级… 端午假期我翻译了 OReilly 的报告《什么是 eBPF》其中我觉得第五章「云原生环境中的 eBPF」解答了我心中的很多疑惑比较不错分享给大家。下面是第五章译文。《什么是 eBPF》中文版封面近年来云原生应用已呈指数级增长。在本章中我将讨论为什么 eBPF 如此适合于云原生环境。为了更具象化我将提到 Kubernetes但同样适用于任何容器平台。每台主机一个内核要理解为什么 eBPF 在云原生世界中如此强大你需要搞清楚一个概念每台机器或虚拟机只有一个内核所有运行在该机器上的容器都共享同一个内核 1 如 图 5-1 所示内核了解主机上运行的所有应用代码。图 5-1. 同一主机上的所有容器共享一个内核通过对内核的检测就像我们在使用 eBPF 时做的那样我们可以同时检测在该机器上运行的所有应用程序代码。当我们将 eBPF 程序加载到内核并将其附加到事件上时它就会被触发而不考虑哪个进程与该事件有关。eBPF 与 sidecar 模式的比较在 eBPF 之前Kubernetes 的可观测性和安全工具大多都采用了 sidecar 模式。这种模式允许你在与应用程序相同的 pod 中单独部署一个工具容器。这种模式的发明是一个进步因为这意味着不再需要直接在应用程序中编写工具代码。仅仅通过部署 sidecar工具就获得了同一 pod 中的其他容器的可见性。注入 sidecar 的过程通常是自动化的所以这提供了一种机制以确保你的所有应用程序都被仪器化。每个 sidecar 容器都会消耗资源而这要乘以注入了 sidecar 的 pod 的数量。这可能是非常重要的 —— 例如如果每个 sidecar 需要它自己的路由信息副本或策略规则这就是浪费关于这一点Thomas Graf 写了一篇 关于服务网格 sidecar 与 eBPF 的比较。Sidecar 的另一个问题是你不能保证机器上的每一个应用程序都被正确检测。设想下有一个攻击者设法破坏了你的一台主机并启动了一个单独的 pod 来运行比如加密货币挖矿程序。他们不可能对你有礼貌用你的 sidecar 可观测或安全工具来检测他们的挖矿 pod。你需要一个单独的系统来了解这种活动。但同样的加密货币矿工与运行在该主机上的合法 pod 共享内核。如果你使用基于 eBPF 的工具如 图 5-2 所示矿工会自动受到它的影响。图 5-2. 旁观者只能观测到他们自己 pod 的活动但 eBPF 程序可以观测到所有活动eBPF 和进程隔离我主张将功能整合到一个单一的、基于 eBPF 的代理中而不是每个 pod 的 sidecar 中。如果该代理可以访问机器上运行的所有 pod这不是一种安全风险吗我们不是失去了应用程序之间的隔离而这种隔离可以防止它们相互干扰吗作为一个容器安全领域的过来人我可以体会到你对此的担忧但重要的是要挖掘底层机制以真正理解为什么它不是一开始可能出现的缺陷。请注意这些 pod 共享同一个内核而内核原生不能感知 pod 或容器。相反内核对进程进行操作并使用 cgroup 和 namespace 来隔离进程。这些结构由内核监管以隔离用户空间中的进程防止它们互相干扰。只要数据在内核中处理例如从磁盘中读取或发送到网络中你就依赖于内核的正确行为。只有内核代码控制文件权限。没有其他层面的东西可以阻止内核忽略文件权限的东西内核可以从任何文件中读取数据 —— 只是内核本身不会这样做。存在于 Linux 系统中的安全控制措施假定内核本身是可以信任的。它们的存在是为了防止在用户空间运行的代码产生不良行为。我们在 第二章 中看到eBPF 检查器确保 eBPF 程序只能访问它有权限的内存。检查器检查程序时不可能超出其职权范围包括确保内存为当前进程所拥有或为当前网络包的一部分。这意味着 eBPF 代码比它周围的内核代码受到更严格的控制内核代码不需要通过任何类型的检查器。如果攻击者逃脱了容器化的应用程序而到了节点上而且还能够提升权限那么该攻击者就可以危害到同一节点上的其他应用程序。由于这些逃逸是未知的作为一个容器安全专家我不建议在没有额外安全工具的情况下在共享机器上与不受信任的应用程序或用户一起运行敏感的应用程序。对于高度敏感的数据你甚至可能不希望在虚拟机中与不受信任的用户在同一裸机上运行。但是如果你准备在同一台虚拟机上并行运行应用程序这在许多不是特别敏感的应用程序中是完全合理的那么 eBPF 就不会在共享内核已经存在的风险之上增加额外的风险。当然恶意的 eBPF 程序可能造成各种破坏当然也很容易写出劣迹的 eBPF 代码 —— 例如复制每个网络数据包并将其发送给窃听者。默认情况下非 root 用户没有加载 eBPF 程序 2 的权限 只有当你真正信任他们时你才应该授予用户或软件系统这种权限就像 root 权限一样。因此必须小心你所运行的代码的出处有一个倡议正在进行中以支持 eBPF 程序的签名检查来帮助解决这个问题。你也可以使用 eBPF 程序来监视其他的 eBPF 程序现在你已经对为什么 eBPF 是云原生工具的强大基础有了一个概念下一章给你举一些来自云原生生态系统中的 eBPF 工具的具体例子。参考1. 这基本正确除非你使用的是虚拟化技术像 KataContainer、Firecracker 或 unikernels 这样的方法每个 “容器” 在自己的虚拟机中运行。 ↩︎2. Linux CAP_BPF 授予加载 BPF 程序的权限。 ↩︎点击阅读原文跳转到网页阅读本书。
