eBPF: Reliable Policy Setting and Enforcement
PARIS — eBPF and tools built with eBPF are often seen as either providing observability, security or networking functionality. But arguably, all these things are at play in many cases as hooks with eBPF from the kernel and extend throughout applications and infrastructure running across environments.
The power of eBPF largely lies in its computing efficiency since it is directly tied to the Linux kernel. However, labeling eBPF solely as a Linux kernel-based tool would be misleading, as its impact is spread across the stack, impacting the applications to which it’s applied.
eBPF is being utilized in diverse ways and has formed the foundation of numerous successful commercial projects. For security purposes, it has been a driving force. Overcoming obstacles that once hindered eBPF adoption has paved the way for various tools and platforms that not only surmount these challenges but also enhance efficiency across security, observability, networking and other applications.
This is largely because companies or organizations that wish to leverage eBPF might lack the resources to develop in-house hyperscalers or the expertise to directly harness eBPF’s advantages. This is where eBPF tool providers and platform providers come into play. Their expertise fills the gap, encompassing an understanding of Linux (technically Unix) to create processes using kernel code needed to run eBPF applications or devices. Furthermore, some Linux kernels do not support eBPF, but tool providers have worked around this limitation.
Because policy can be managed properly with the right tools through a single API, this means that with the single API, policy can be set and better enforced with the use of eBPF. With eBPF, policy is set in such a way that when an event happens — such as an attack or when policy is violated during the entire application lifecycle — more than just alerts and logs can be issued.
eBPF’s hooks dig deep and wide, so that the severability or other information about an attack or policy violation is detailed. Information about what exactly the problem is can be provided in addition to the mere listing of logs or sending alerts.
As Liz Rice, chief open source officer for Isovalent, describes in her book, Learning eBPF: Programming the Linux Kernel for Enhanced Observability, Networking, and Security how the functionality of using eBPF for policy involves defining what is and isn’t expected behavior (this includes when suspected error paths are detected) and identifying when abnormalities are detected. But eBPF also goes much further as Rice writes: “The more contextual information that’s available to the investigator, the more likely they will be able to find out the root cause of the event and determine whether it was an attack, which components were affected, how and when the attack took place and who was responsible.”
Setting and enforcing policy on Kubernetes for microservices is a moving target, given the stateless and highly distributed nature of Kubernetes. At KubeCon + CloudNativeCon during the talk “How Many Network Policies Can I Create?” with Shaun Crampton, distinguished engineer at open source Calico creator Tigera, Nadia Pinaeva, a senior software engineer at Red Hat, said network policy for cloud native can be described as a Kubernetes API that ensures network security. Its structure is very simple and it has just one ingress rule that allows connections from a specific namespace with a project name, my project, Pinaeva said. “What it does, is it allows you to specify connections that should be allowed for a specific set of pods, and then everything else will be denied. So here is a simple example that you can see,” Pinaeva said. “That’s a network policy that is created in the default namespace, and it isolates all the pods in that namespace.”
On a very rudimentary level, if an attacker succeeds in reconfiguring an application so that it’s written to a different location, then that alert is issued. And again, this can take place, it’s supposed to ostensibly take place anywhere. So, ostensibly, from a policy enforcement perspective, this aspect involves security, but I would argue that it’s observability as well, given that it offers more visibility into problems that occur based on settings that correspond or not.
And what triggers the events is determining whether the policy that is set, again, from a single API, is being met or violated. When it’s violated, alerts are issued with more information provided than just a single rudimentary security tool. So, one could argue that it encompasses observability, security, and networking as well. In any case, during KubeCon+CloudNativeCon, this subject was approached and demonstrated how this trend unfolds.
It looks straightforward but of course it’s not-Jeremy Guerrand on Using Calico Policies to Secure @Kubernetes Traffic. @tigeraio @KubeCon_ @thenewstack pic.twitter.com/3CrqNuShjm
— BC Gain (@bcamerongain) March 19, 2024
During CalicoCon, a colocated event held during nearby KubeCon + CloudNativeCon Europe 2024, Jeremy Guerrand, solutions architect at Tigera, which is the leading development of open source Calico dataplanes, gave a talk entitled ”Best Practices: Using Calico Policies to Secure Kubernetes Traffic,” He noted eBPF’s role in helping to make Calico widely deployed for setting network policy for Kubernetes. During this talk, he said conventional approaches “in multicluster, zone-based architectures” lack visibility, and hence, observability. They give overly broad IP range allowances, leading to a larger attack surface, he said. With Calico policies, you can define, test, and enforce stringent traffic rules between pods and services within Kubernetes. It provides detailed control over both ingress and egress traffic, effectively isolating workloads, enhancing network performance, and ensuring compliance with various security standards, he said.
Not to say that applying Calico to tackle policy setting and maintenance does not require much practice and know-how, the eBPF functionality can be succinctly described. With Calico, instead of using standard eBPF hooks, it uses programmable trace points and other ways “to get the job done” through creating YAML tracing policies, Guerrand said.
During the demo shown during Crampton’s talk, he set up a cluster in GCP, so that kube-burner, a Kubernetes performance and scale test orchestration framework, supports arbitrary Kubernetes clusters, without being “in any way tied to OpenShift.” He enabled Prometheus metrics in Calico with a persistent results server with Grafana and OpenSearch. Pinaeva’s repo with the YAML files that included Calico’s contribution was, of course, used as well.
During her talk, Pinaeva displayed the network policy scale profile, which in this case had seven parameters. While applicable to the demo shown during the talk, her comment can also be used to describe using eBPF for policy — with Calico as the main tool — in general. “This is the thing that defines how network policy YAML will look like, and that is good enough to understand what is the scale impact of a given network policy,” Pinaeva said. “Now I hope at this point it is obvious that there is no single or simple answer to how many network policies can I create.”
