While most organizations don't have direct access to EBPF expertise at the moment, this year there is the option to configure a tool that is configured with an EBPF and feature extension layer, which will be more helpful.
Translated from ebpf: meaner hooks, more webassembly and observability due, by bCameron Gain is the founder and principal analyst of Revecom Media. His obsession with computers began in the early '80s of the 20th century, when he hacked the Space Invaders console to play continuously at the local arcade for 25 cents a day. The EBPF has undoubtedly achieved its promotional effect in 2023, and in 2024 we will see more interesting developments. This is mainly because the EBPF has proven its suitability, with its continued adoption in monitoring, observability, networking, and security, as well as the tireless efforts of the open source community. It all started with the merger of the Berkeley Packet Filter with the Linux kernel in 2010, before becoming an "extension" in 2014 and called EBPF. Today, EBPF has demonstrated the value of the various logs, metrics, traces, and other information it can provide through hooks. These hooks come from the underlying applications, infrastructure tools, CI CDs, and deployed Linux kernels that support developers, operations teams, and SREs. That said, there are still some challenges for it to reach its full potential.
Let's see what to expect in 2024.
There has been a lot of progress in open source work last year or in 2023. Highlights include the graduation of Kubernetes and cloud-native EBPF projects such as Cilium from CNCF. In addition, the applicability and adoption of EBPF continues to increase through tools such as Kubescape, Inspektor Gadget, Hubble, Tetragon, and Falco. And, as Gartner points out, it's worth noting that these open source developments leverage EBPF, and these tools are helping organizations meet their business and security observability needs. Gartner recommends that most enterprises lack the expertise to leverage EBPF directly, and should choose a tool that is configured with EBPF and a functional extension layer.
Gartner analysts Tony Harvey and Jason Donham wrote in the "2023 Computing Power Hype Cycle": "While this is realistic for technology vendors and hyperscalers, most enterprises lack the expertise and skills needed to build and integrate EBPF-based capabilities. In other words, using EBPF in a sandbox environment can be fun, but don't try it without trusting the established EBPF tools and processes to ensure your organization's security strategy.
At the same time, the solution will depend on how the open source projects that primarily support the development of EBPF are continuously improved and delivered.
Torsten Volk, an analyst at the Enterprise Management Association (EMA), said: "Currently, EBPF is primarily a 'passive' technology that listens directly from the operating system kernel to relevant system data. For example, this passive nature limits the degree of automated detection that an EBPF-based observability platform can provide. "If EBPF allows these observability platforms to pass contextual data through the system call and network request auto-detection process, then auto-instrumentation can become more out-of-the-box because it can be used to correlate kernels and applications. According to Volk, this automatic detection can be automatically compiled into the application without requiring any changes from the application development team. "However, while I describe this level of auto-detection as the 'holy grail of observability,' allowing applications to make changes to system data at the kernel level can become a very tricky issue because of the potential impact of these changes on system security, stability, and overall performance. Volk said. "On the other hand, auto-detection at the kernel level can even improve application performance because EBPF compiles and runs faster than interpretation. ”
EBPF owes much to its unique ability to not only provide observability for vulnerability and attack detection, but also to identify and remediate vulnerabilities. In addition, it plays a key role in differentiating and providing context for vulnerabilities that can be distinguished from attacks that require immediate remediation or minor misconfigurations that occur in the CI CD process.
As Liz Rice, Chief Open Source Officer at Isovalent, writes in the book Learning EBPF: Programming the Linux Kernel for Enhanced Observability, Networking, and Security, "The difference between a security tool and an observable report event is that a security tool needs to distinguish between an event that is expected under normal circumstances and an event that indicates potentially malicious activity." Rice emphasized that EBPF as a core technology enables the creation of tools "built on top of incident detection, resulting in EBPF-based security tools that can detect and even prevent malicious activity." In this way, Liz concludes that EBPF differentiates security from other forms of observability. We anticipate more integrations with EBPF tools and projects. For example, the Cilium created by Isovalent will be widely integrated with a variety of tools and processes. For example, CILIUM's Border Gateway Protocol (BGP) function is extended to allow Kubernetes workloads to seamlessly connect with traditional service workloads. and integrating Tetragon's security incident reporting with SIEM to provide security teams with detailed forensics to investigate malicious incidents, Rice said in an interview with The New Stack. In addition, integration with other technologies will be added, such as WebAssembly, which is promising, although not as stable as EBPF. This integration will take advantage of WebAssembly's ability to distribute applications into channels that connect endpoints, with EBPF helping to maintain a closed loop. "We can think of WebAssembly as a user-space sandbox and EBPF as a kernel sandbox, each allowing for customization in their respective domains," Rice said. "Therefore, it is reasonable to expect that infrastructure tools may combine the capabilities of both in a complementary way. An example of this integration is the custom advanced L7 processing in the Wasm Envoy plugin, combined with the Cilium network implemented with EBPF," says Rice, "to create advanced and dynamic networking capabilities that meet the organization's customization needs." ”
Eventually, EBPF could be compiled into WebAssembly, automatically injecting observability into application containers, and possibly auto-instrumentation, "no matter what they're running," Volk said. "The integration of EBPF with WebAssembly is really exciting," says Volk. "From a security perspective, since EBPF runs in the kernel and WebAssembly runs in the user space of the Linux operating system, combining the two can provide enhanced isolation for the full application stack. ”
There is no doubt that AI will not only have a profound impact on society in the coming months and years. It will be very interesting to see how AI can be applied or used in conjunction with EBPF. This is still a very general idea, as the practical application is not yet clear. Speculation about how the EBPF will manifest or how AI will integrate with the EBPF is pure speculation.
At the same time, it's interesting to see how the web, in particular, can be used in conjunction with EBPF, rather than just relying on LLMs like ChatGPT for cybersecurity. It will be interesting to see how this dynamic develops in 2024. "An example of what I expect is a network policy created by AI and executed by CILIUM," Rice said. "We've seen some experiments in this area, like most ChatGPT apps, that aren't reliable enough to rely on it, but I expect this to improve. ”
In addition, Volk said, using EBPF to add kernel-level data from the operating system's user space to the current telemetry stream provides important context for LLMs to make better decisions and recommend more specific remedial actions to human safety engineers. "Further, the integration of EBPF with LLMs allows LLMs to implement and evaluate security policies based on their impact at the system level," Volk said. "That's where things get very technical. ”
EBPF is designed to provide network-wide customization capabilities, extending from the kernel or across runtimes, especially for Kubernetes. However, since EBPF is integrated with the Linux kernel, this can be a security issue for some. After all, no one wants a malicious ** with direct access to the operating system and CPU except an attacker.
To address this EBPF security issue, the EBPF validator checks** and only grants EBPF write access if the validator is licensed under the GPL. Of course, nothing is completely preventable. As Rice points out, validators check that the program is running safely, but there is no guarantee that the program is not malicious. "For example, I might write an EBPF program that drops packets at an address because it's the first of malicious traffic, or I might write a program as a hacker to block an address for some bad purpose," says Rice. "Validators can't tell the difference between the two. As mentioned above, it's equally important not to customize your own eBPF tools in-house, but to rely on properly vetted vendors. "That's why it's important to only load and run EBPF programs from the best vendors you trust," Rice said. Work is underway in the kernel to help users validate the ebpf program (much like the application's chain security check).
I'm actually involved in these things for fun, when it drives goodwill. Therefore, I expect and hope that a vulnerability will be disclosed in 2024, not only for fun, but also to further harden the EBPF for network encryption.
However, as Rice points out, "EBPF can customize network functionality extensively, but it is more typical to rely on other kernel cryptographic implementations (such as Wireguard) rather than encrypting in a custom EBPF program." ”
In addition, by definition, when you increase the ability of the application layer to interact with the kernel layer, the attack surface of the system also increases, Volk noted. "It's intuitive, because that's why Linux was originally created to separate the kernel from the application," Volk said. "However, so many years have passed since Linux was first created, and we may now have a way to allow applications to conditionally access the kernel without risking the entire farm being compromised. ”