In Conversation with Liz Rice, Chief Open Source Officer at
Liz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project.
Updated
On this page
Updated November 2026. This was first published on 21 November 2022. The idea is the same. Any number below is what the original piece said then. It is not a new count. This is a record of a conversation from that day. No new quotes were added.
Key takeaways
- Liz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project.
- She was Chair of the CNCF’s Technical Oversight Committee 2019-2022, and Co-Chair of KubeCon + CloudNativeCon in 2018.
- She is also the author of Container Security, published by O’Reilly.
Liz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project. She was Chair of the CNCF’s Technical Oversight Committee 2019-2022, and Co-Chair of KubeCon + CloudNativeCon in 2018. She is also the author of Container Security, published by O’Reilly.
She has a wealth of software development, team, and product management experience from working on network protocols and distributed systems, and in digital technology sectors such as VOD, music, and VoIP. When not writing code, or talking about it, Liz loves riding bikes in places with better weather than her native London, and competing in virtual races on Zwift.
**Q: Most of our readers might not understand the kernel. Can you explain what the kernel #
Operating systems have two parts: userspace and the kernel. Userspace has lower privileges; kernel space is a fully privileged environment. The kernel is the only part that can directly access memory, files, network, or any other hardware component. Userspace applications where we typically operate have to ask the kernel to do things on its behalf.
As developers, we write application software; and applications run in userspace. If you’re writing an application and want to read from a file, send a network message, or display something to the screen, you can’t do it directly. you have to ask the kernel to do it for you. Usually, that’s hidden from you because we have language abstractions that hide the interface. But in practice, your application is making system calls to ask the kernel to act on its behalf. The kernel is also doing things like scheduling multiple applications to run concurrently.
Q: How does the userspace interact with the kernel space? #
There is an API called the system call or syscall interface, and there are over 300 different system calls. In most programming languages, we don’t write directly to the system call; there’s usually an abstraction. In the world of C, we talk about the standard library, and many other languages build on top of that. For example, if you open a file, you probably have a language-specific function called ‘open’. When you call that, underneath the covers, it will make a system call to an open syscall to open that file on your behalf.
**Q: What is packet filtering? What is Berkeley packet filtering? And what is the extended #
Okay, so this is a bit of a history lesson. Berkeley packet filtering was a paper written from the Berkeley Lab; that’s where it gets the Berkeley part of the name. The idea was that as packets arrive into the kernel you might want to take a copy of certain packets to examine them in user space, that’s packet filtering. But packet filtering is just a small part of what we now call BPF and eBPF, so honestly the acronym isn’t all that helpful today.
eBPF is a way of running custom code within the kernel. Normally, we write applications that run in user space. with eBPF, we can run custom programs within the kernel, load them dynamically, attach them to kernel events, and change the behaviour of the kernel.
**Q: Earlier, you mentioned that userspace is a less privileged environment. If eBPF progr #
The first thing is that it has to be treated with respect. If you allow someone to load eBPF programs, they need to be privileged. There is a Linux capability called CAP_BPF that you need to give people the same way you would give out root privileges. you have to treat it like root. If someone can load eBPF programs, they can do anything on your system.
The thing that makes BPF programs safer than kernel modules is the ’eBPF verifier’. Whenever you load an eBPF program into the kernel, it goes through a verification step. It makes sure that it’s safe to run the program, and it would definitely reach a conclusion, i.e., it’s not going to loop indefinitely. It’s never going to dereference a null pointer because that would make it crash; the whole machine dies if you crash the kernel. It also checks that any memory access is as expected. For example, if you’ve attached an eBPF program to receiving network packets, you’re only allowed to look at the network packet’s memory. You can’t just look at arbitrary memory across the system. So, the verifier makes sure that programs will be safe to run and that they’re doing sensible memory access.
**Q: If eBPF is so powerful, why is the industry still following the sidecar pattern for s #
That’s exactly what we’re doing with the Cilium project. Cilium enables networking, visibility, and security using eBPF and without needing sidecars. There are other examples of eBPF enabled networking. For example, Facebook has built a load balancer called Katran, and Cloudflare has eBPF-enabled load balancers too. It has taken time for eBPF networking to be widely adopted. you need eBPF support in the version of the Linux kernel that you’re running. It can take several years for what it does in the Linux kernel to make it into a Linux distribution. Maybe two years ago, not everybody could really use eBPF. they were using older kernels that pre-dated eBPF, but now it’s so widespread. That’s why eBPF has really taken off in the last year or two.
**Q: What are the advantages and what are the drawbacks of eBPF for routing and observabil #
eBPF, particularly for Kubernetes networking and container networking, turns out to be a real performance improvement. And the reason for this is that when you run containers, or Kubernetes pods, you typically have a network namespace for each pod. It has its networking stack in that network namespace, and there is also a network namespace on the host with its own network stack. Suppose you imagine a packet arriving physically at a machine through the host’s network interface, a physical network card. In a traditional networking setup the packet will go through the host’s networking stack, then it gets forwarded to a virtual network connection into the pod where it has to go through another network stack in that pod, to arrive at the application.
With eBPF, we can hook in as soon as the packet arrives. We can look at the destination address, recognize that it’s going to a pod and send it directly to that virtual ethernet connection for the pod, bypassing the host’s networking stack. That makes it dramatically faster than the traditional networking approach. It is almost as fast as if you were running networking just from one node to another without any containers at all. And we can also collect observability data about network flows, and provide security controls really efficiently using eBPF.
**Q: Wonderful! It looks like eBPF is a real game changer! We can save a lot of operationa #
So the good news is you can very easily install Cilium on all of the cloud providers. Google already uses Cilium as the default for the GKE data plane. Amazon uses Cilium as the default data-plane for EKS anywhere. A lot of managed Kubernetes services are also opting to use Cilium as the network setup, now that kernel support for eBPF is so widespread, and because there are a lot of performance benefits from using eBPF based networking - and Cilium is a really good setup.
**Q: If eBPF is so powerful, why is the industry still following the sidecar pattern for s #
I would say take a look at Cilium, as we have sidecarless service mesh in beta right now. Because it’s in beta, I wouldn’t say upgrade all your Production nodes just yet! And what we’ve done with the eBPF-based service mesh is, we already talked about the kind of networking performance improvements that we can have. we can also make resource savings by avoiding sidecar injection. In service mesh, we have this extra proxy component that’s normally injected into every single pod. If you’ve got, let’s say, 1000 pods in a cluster, routing information has to be duplicated in 1000 sidecar proxies. And you also have this extra networking step that you need to send every packet through. By using an eBPF-based data plane, we can avoid having to inject the proxy into every single pod, we can just have one proxy per node. So it’s much more efficient from a routing table point of view, and it’s much more efficient from a network path point of view. And yeah, so keep an eye on the Cilium service mesh beta. that’s going very well, we have an Ingress setup and although it’s early days we’re seeing some really good performance numbers. There are a few features that will be coming in future releases, like SMI integration.
Q: What is your advice for people getting started in open source? #
I would say find a good and welcoming community. Kubernetes has a really strong community, there are lots of other CNCF projects that are very welcoming. Look for projects that excite you, and that you want to get involved with and ideally if it’s interesting for your current employer, that’s helpful from a career point of view.
Don’t be afraid to raise your hand and ask your questions.
Find the Slack channels, discord channels, GitHub repos, and don’t be afraid to ask for help. The best open-source communities are really very supportive.
Questions and answers #
What is the main point? #
Liz Rice is Chief Open Source Officer with eBPF specialists Isovalent, creators of the Cilium cloud native networking, security and observability project.
What else did the original piece say? #
She was Chair of the CNCF’s Technical Oversight Committee 2019-2022, and Co-Chair of KubeCon + CloudNativeCon in 2018.