In this RedMonk conversation, Alex Zenla, founder & CTO at Edera, chats container security and virtualization with Rachel Stephens, research director at RedMonk. Alex shares her unique journey from Minecraft to the tech industry. She emphasizes the importance of security in computing, particularly in the context of IoT and legacy systems. The conversation also explores the differences between eBPF and secure design principles, as well as the potential of WebAssembly in the tech landscape and a proactive approach to security in technology.
Links
Transcript
Rachel Stephens (00:12)
Hi everyone, welcome to the MonkCast. I’m Rachel Stephens and I’m so excited today to introduce you to Alex Zenla. Alex is the CTO of a company called Edera. Alex, could you please introduce yourself to everyone and tell us what are you doing at Edera?
Alex Zenla (00:25)
Yeah, hi. Great to be here. Obviously, my name is Alex Zenla. I’ve been here at Edera for almost a year now. Started, incorporated back in April, so very exciting. And we do container security technology and computing security technology using virtualization. It’s a very deep tech and extremely interesting topic, especially in this day and age with AI and computing.
Rachel Stephens (00:52)
So company is slightly less than a year old. How big is the team?
Alex Zenla (00:55)
It’s growing every day, so it’s hard to remember exact numbers, but more than 10, less than 20, something like that. Yes. We are completely remote. I am currently bouncing between Florida and Washington state. My home is Seattle, Washington.
Rachel Stephens (01:02)
So it’s in the fun growth stage, very fun. And where are you all based out of?
Alex Zenla (01:18)
Uh, and, uh, we have people, uh, our CEO Emily is in, uh, Santa Barbara, which is a very beautiful place as is Seattle. Um, we have some people in Colorado and New York, so all over the place.
Rachel Stephens (01:32)
I love this story. I want to hear the story about why you decided to build the company in this space in the first place. Why is this a space you decided to go after?
Alex Zenla (01:41)
Yeah, great question. Well, as you’ll learn in a moment, I have a very atypical background. So I feel like I have to talk about it if I’m going to talk about why I started Edera. So I guess the most important thing is I grew up in a rural town in Alabama, not great access to technology.
My parents were teachers and worked in education. And about the only access I had to technology was really school technology and things like that. And I was lucky to get a hand-me-down computer from someone. And when I was 11 years old, I did not have the money for a Windows license, so…
I acquired Linux at the time Ubuntu was the big deal. And naturally, I think I was a bored kid, so started working on Ubuntu packaging and like software packaging and that kind of thing. Very exciting and interesting community. And naturally, being 11 and 12, and going on to 12, Minecraft was huge.
at the time. And my sister bought me Minecraft for my birthday in 2012 when I was 12 years old. Just turned 12. And I started playing the game and wanted to make modifications to it. So I learned programming. I would argue probably through shell scripts and things like that for
Ubuntu got me interested in it, but then really accelerated with Minecraft. And then from there, I started working in the language Dart, back when that was not popular at all. It’s a very fledgling language from Google. I was very involved in the Chrome OS community and things like that. And so I got invited to Google I.O. 2012 by Google.
when I was 12 or 13, which has its own story that could probably be its own podcast. But essentially being involved in Dart got me involved in IoT, Internet of Things stuff, which I was born and raised in Internet of Things technology. So I worked the last 10 years in IoT tech and the security aspects that Internet of Things are fascinating.
Rachel Stephens (04:04)
Yeah.
Alex Zenla (04:04)
I had a very weird part though in that I was doing industrial IoT and not home IoT. In industrial IoT security is an all important aspect. And I could not find a good way to securely run applications at the edge, particularly containerized applications. And I really struggled with…
the way the computing primitives that we have these days. And I knew that there needed to be something new. So Edera was born out of my lessons that I learned from the Internet of Things and allows you to segment and isolate containerized applications into separate virtual machines, all without hardware virtualization. So it’s very powerful technology.
Rachel Stephens (04:53)
That is a hell of a story. And I love that. So why did I, why did I found this company story? That’s fantastic. All right. So you’re talking about compute primitives. Like, Why is containerization not enough? And why is like, why is computer like hardware virtualization? Why is that not enough?
Alex Zenla (04:55)
Yeah, great questions and very important. And I think there’s a lot, a lot to be talked about in this space. And I’m very happy that Edera will be doing more on this, but particularly containerization, I think people in general think that it is more than it really is right now. I would venture to guess that some
greater than 10 % of people that are aware of containers probably believe that what’s happening in the backend is something like a virtual machine. But that’s actually not the case. Containerization, as we typically know it, for example, from Docker, is effectively something in the Linux kernel called namespaces. Namespaces…
Namespaces are effectively a way of isolating resources, but at the kernel level. So everything on the Linux kernel is all in one thing. It’s all in one address space. If you ever heard the Linux kernel called a monolithic kernel, that’s what that means. And unfortunately, what that means is that namespaces are kind of a soft isolation.
They segment resources based on effectively raw logic and the code that separates things. For example, if you have an open file, there’s mount namespaces, which can kind of separate mounts and those kinds of things. The problem with namespaces is that it’s still all in the same kernel address space. So if you exploit
a vulnerability in the Linux kernel, you can exploit everything in every container across the entire operating system. So if you have five containers running in Docker and one gets exploited, you cannot trust that any of the other containers are not exploited. In fact, they almost guaranteed to be exploited if you have kernel access.
This is a known problem. I would argue that people were aware of this when stepping into containers at the start, and they accepted it because containers had such a great usability compared to the old way of giant virtual machine images. But it comes with just a security nightmare, and we’ve seen this play out, and various vulnerabilities.
The one that comes to top of my mind is the dirty pipe vulnerability, which was a CVE that effectively eliminated the security of namespaces. and allowed you to effectively escape a container. So the solution to this is to place individual containers in virtual machines. In Edera’s
parlance we call this zones. And zones basically are a full Linux kernel running in a virtualized context that runs a container separately in a zone. So we give you this extra computing primitive between your base operating system and the application, which allows you to segment and securely isolate things.
The great thing about virtual machines is that you no longer have the single address space that’s insecure. You have a division line that’s hard enforced. When you have hardware virtualization, that can actually be enforced by the hardware. However, you do not have to have hardware virtualization in order to do virtual machines. I think this is a very common misconception.
The Linux KVM architecture does require hardware virtualization by design. But we utilize the technology based on Xen that allows us to virtualize the operating system in separate zones without requiring hardware virtualization. Why do you want to have this without hardware virtualization? Because hardware virtualization is not always available in all environments.
For example, on Amazon AWS, it’s not available on most instance types and the instance types that have hardware virtualization are all instance types that cost significantly more because you’re effectively buying an actual physical server and renting time off of that rather than a part of a server. And in different clouds, it differs as to whether or not you get that hardware virtualization.
And just real quick, going back to my IoT experience, the key problem I was trying to solve was that in the Internet of Things space, you might be running on many different types of hardware, hardware that you do not necessarily control. And when you don’t control the hardware, you can’t rely on hardware virtualization to be available. And that is where this, this
Rachel Stephens (09:57)
Mm-hmm.
Alex Zenla (09:59)
non-requirement hardware virtualization is so critical and it’s the key thing that I recognized.
Rachel Stephens (10:06)
So this would be doing the virtualization then at the software layer, not the hardware layer.
Alex Zenla (10:11)
Correct. The best mental model that I think of it is if you control both the operating system you’re virtualizing and the hardware that you are running that on, as in the software that runs on that hardware, you do not need hardware virtualization to get performant virtual machines.
need hardware virtualization only when you don’t control the thing that is running inside what we would call a zone. So for example, if you have a Windows system, you can’t modify or load significant amounts of drivers that would allow you to run on something like Xen very easily. But on Linux, Linux has the built-in support for something like Xen to be able to virtualize without hardware support.
Rachel Stephens (10:57)
Gotcha. And Xen can run pretty much anywhere. It can run in IoT environments,
Alex Zenla (11:03)
in fact, Xen runs in lot of automotive environments. By far the most interesting use case outside of what I believe we have here is the automotive space and ARM64 Xen is very popular. Recently Honda joined the advisory board, I believe it is, of the Xen Project, because
they utilize Xen on their cars. And there are other vendors as well. I think at one point, and maybe even still, Tesla used Xen on their cars in some places. But I know that many, many vendors in that space have used it. So it’s very powerful and flexible.
Rachel Stephens (11:42)
Interesting. So I want to talk just a little bit about… some maybe adjacent approaches when you’re kind of talking about compute primitives upfront.
Talking about containerization, think is obviously one approach. I think maybe some people out there might be familiar with other approaches. And I think especially given what I know of some of the founding members of your company, you pulled heavily from the Chainguard team when you formed the company. How does this compare with something like an eBPF technology? And how does it differ?
Alex Zenla (12:06)
Yeah, fantastic question. So eBPF can do many things. It can monitor an operating system kernel. But one thing that it really struggles with is that eBPF is running inside the kernel itself. There’s a famous post from grsecurity that talks about this exact problem of eBPF-related technologies.
Rachel Stephens (12:24)
Mm-hmm.
Alex Zenla (12:34)
where if you find an exploit in the kernel, you can effectively turn eBPF off or remove any of the monitoring solutions. This is a known problem, I think, by the eBPF vendors out there, and they’re all wonderful, and they do provide great value, and we think that we sit alongside those people. But it is not the end-all, be-all of security. It is a component of the security model.
so I think what we see is, eBPF tends to kind of view the world as so broken that the only way to do anything about it is to monitor, the state of the world. And, I kind of reject that notion that computing has to be naturally super insecure and that the only thing we can do is monitor for that insecurity.
I’m a huge believer in secure by design. It’s something that I wish we could really focus more heavily on. And by the way, a lot of the Chainguard people are very familiar with secure by design, which works out very well in our favor. But the key thing that I feel is secure by design allows you to build a platform
that is naturally more secure from the start, rather than relying on just monitoring or just prevention via eBPF, we want to make the world more secure at the basis of computing while not relying on hardware necessarily to do that. So one of the key things and why we don’t require hardware virtualization is that we want to be able to run anywhere.
And that gives us the power to be able to deploy our technology to secure applications that many people cannot secure. I’ll give just a key example of that. In many large organizations, you are inevitably going to run into legacy software. I’ve seen it in the biggest of the big technology companies.
where you have the odd machine running something from 20 years ago or 10, 15 years ago. It happens to banks, it happens to all sorts of different people.
Rachel Stephens (14:46)
Honestly, I’d be surprised if you didn’t run into something.
Alex Zenla (14:49)
Yeah, exactly.
It’s so common. coming from the industrial IoT space, by the way, I can’t tell you the number of times we were integrating with some device that had software that ran on a server somewhere that hadn’t been updated in 15 years. And what we see in the world is that there’s this push to
always be running the latest up-to-date everything. And I think that’s a very positive move, I think patching vulnerabilities. And I think that kind of thing is important in our space. But what about when you can’t do that? And that is where our product can really fill a role because we’re able to provide security or basically a blast box around any piece of software.
And I think that’s extremely powerful. If you were to run a vulnerable application inside of one of our zones, you instantly get more security because the only thing that that thing can access is itself. And it has no hardware access at all. All it can do is communicate over a very small channel via an RPC mechanism to
our management software, which is written in Rust and designed to be attack resistant. And so I reject the notion that we have to be insecure and that we have to only monitor security vulnerabilities and always be reactive. I think we can be extremely proactive.
Rachel Stephens (16:17)
And speaking of Rust, it’s a lovely segue into my next question. Same general question. Help me understand how this compares to something like a Wasm. And they have this kind of sandbox-based security approach. Where would you maybe want to think about one versus the other?
Alex Zenla (16:22)
Okay.
Yeah, fantastic question. think Wasm is very interesting. I have many friends that work as researchers and developers in the Wasm space. And it’s incredibly cool. Like I think WebAssembly is a very neat technology. One of my kind of side passions is compiler technology and programming language design. And Wasm has like all of the same people that love that stuff working on.
What I see in the industry though is it can be cumbersome. I see Wasm being adopted in a lot of serverless function based systems and I think that’s a great fit. I think that Wasm plugin type stuff is really interesting. But I struggle to see real world user applications being deployed en masse.
in a Wasm world. I think it will always be a relative niche in the market compared to standard Linux applications. think you can kind of see this in some of the… There’s been some prior art and Wasm-ish type things of… There was something that I’m failing to recall correctly, but…
Effectively, it was an ABI, an application binary interface for running cloud applications that was kind of agnostic to the hardware. And I think this kind of technology is very cool. And Wasm is effectively the much more modern version of that. But my experience running an enterprise is that you have things like Java
You have legacy applications and you have non-compiled languages, things that aren’t Rust like Java. And Node.js has great support for Wasm, I believe, the JavaScript community, but many communities still struggle with it or the interfaces for accessing network and server technologies are not quite there yet.
So I think Wasm has a place, but I think that what we are doing is allowing you to run your unmodified container images in a more secure environment that gives you some of the same advantages of Wasm of being sandboxed, but even more so in virtual machines. And I do not think our strategy is also incompatible with a Wasm world. It is…
definitely possible to run Wasm on our platform. And we have plans to potentially add some, you know, Wasm support as people request it. But what we are seeing in the market is that people want to run container images unmodified. The debug ability of the existing tooling is already built out. It will be some time until we see Wasm deployed in any significant capacity and even then I think it will remain a niche.
Rachel Stephens (19:28)
Fair enough. All right, well, anything exciting coming down the pipe that we should know about or anything you want to share?
Alex Zenla (19:35)
There’s so much happening this year. I’m telling you that I feel so happy for our team and, I would put our team up against the best. And I think we have legitimately one of the best teams in the industry. So 2025 will be a huge year for us. I know…
the computing will not get more secure without technologies like ours. And I’m really hopeful that security will become such a big priority in this day and age, especially in today’s AI world where I once talked to someone who described security and computing as kind of a catch-up race where
One person is running like five miles. We run five miles. We do a lot of insecure programming. And then we spend like a year trying to clean up all of that mess. And I’m really hoping this year we will start to really invest in security across the industry and look at technologies as very different like our technology. And one of our inspirations is Grace Hopper.
As you may know, we’re a women-founded company. And so we look up to people like Grace Hopper in history. And there was recently, you know, a few months ago, released a lecture from Grace Hopper that effectively talked about both her philosophy on how she ran her organization.
And there was this great quote that I could never do justice in trying to read out, but I encourage you to look it up about how we never do things the way they’ve always because they’ve always been that way. We should always be doing things the right way, regardless of how we’ve done it before. And I think, you know, I want security to be more like that.
I think we struggle in this industry and across the board with accepting that things don’t always have to be how they’ve always been. And I think containers are great example of that. You know, there’s a lot of people who we talk about our technology with naturally understand that what we’re doing is so huge and important. But then, you know,
I do think it’s important for people to recognize that containers don’t have to be insecure and we don’t have to just pack on tools upon tools in order to think about this security problem as just an impossible task. I think we can change how containers run and make them more secure.
Rachel Stephens (22:13)
Well, Alex, it has been an absolute pleasure having a conversation with you. Thank you so much for taking time out of, I’m sure you’re very, very busy days leading a brand new startup to chat with me. I really appreciate it. And we will watch with interest what you accomplish this year. So thank you so much for your time.
Alex Zenla (22:21)
Yeah, thank you so much, I appreciate it, it’s been great.
No Comments