Zarf

00:01: Welcome and Introduction to Brandt Keller and Defense Unicorns
02:01: What is Zarf and its history: Solving the air-gapped use case
04:33: Zarf’s critical function today: Security, transparency, and packaging
09:18: How Zarf has evolved: From niche tool to agnostic distribution and GitOps integration
12:07: Zarf’s role in OpenSSF and securing open source software
16:05: Rapid Fire and Call to Action (Zarf.dev)

• Brandt Keller’s LinkedIn page
• Zarf Website
• Zarf GitHub
• CNCF Security Technical Advisory Group (TAG Security)
• OpenSSF Software Supply Chain Integrity Working Group
• OpenSSF Project GUAC
• Defense Unicorns
• Get involved with the OpenSSF
• Subscribe to the OpenSSF newsletter
• Follow the OpenSSF on LinkedIn
• Join the OpenSSF

Sally Cooper (00:01.748)
Hello, hello, and welcome to What’s in the SOSS, where we talk to amazing people that make up the open source ecosystem. These are engineers, developers, maintainers, researchers, and all manner of contributors that make open source so great. I’m Sally, and today I’m really excited to be joined by Brandt Keller from Defense Unicorns. Brandt, thank you so much for being here.

And to get us started, can you tell our listeners a little bit about yourself, your role, and the kind of problems you focus on at Defense Unicorns?

Brandt Keller (00:35.742)
Absolutely. Thanks for having me. so yes, I’m Brandt Keller, primarily, a Staff Software Engineer at Defense Unicorns where I get to, know, I have the privilege of getting to focus on open source software, and maintaining that across both the open source software, projects that we have created as well as kind of the intersection of all of the things that we depend on as a company, we want to be able to be, you know,

appropriate stewards for not only consuming, but also trying to, you know, identify how we can contribute back. And so my role in particular is that of a maintainer for Zarf, which is an OpenSSF Sandbox Project. And outside of that, trying to be more of a, you know, kind of advocate in a few different spaces.

The software supply chain integrity group, working group under the OpenSSF. I try to be a contributor there, in the CNCF spaces. also contribute to, the security and compliance technical advisory group as a technical lead. And so kind of, you know, broad span, but have the definitive privilege of getting to kind of work with communities, build communities, and build technology.

Sally Cooper (02:01.972)
Oh, wow. This is so exciting to have you on the show, especially to talk about Zarf. So you mentioned Zarf. And I was just wondering if you could tell our listeners, I’m sure many of them know what Zarf is. But for those who don’t, what is Zarf and what’s its history?

Brandt Keller (02:19.02)
Yeah, for Zarf in particular, it’s, it’s evolved for sure. But I think kind of at the, at its cusp, it’s always been about trying to take this process of like, where does our software come from? and that the answer to that is varying and nuanced for everyone. but wherever it comes from, let’s try to find a way that we can package it up in a way that’s reliable and repeatable to make it secure. Ultimately, ultimately we really want to lean into that security posture.

and so what happens is software comes from many different places. people are running Kubernetes everywhere. and they have to collect all the disparate puzzle pieces in order for things to run. They have to collect their container images, their helm charts, every other file that they need to run an application. Maybe it’s their application. Maybe it’s an open source application, that their environment relies on. and we want to make that.

As easy as possible in such a way that it’s, you know, very transparent. You have everything you need. And when I say that, you know, you can maybe get to your environment and find out that you missed a piece and maybe that’s okay. But for Zarf in particular, we’ve always built for the air gapped use case, the most critical environments that don’t have connectivity back to any upstream internet connection. they have a pretty big problem here where there is no reaching back and grabbing that thing. You have to go back out and bring it back in. And that’s, been a lot of consternation for people who operate in these environments. so. Zarf really wants to make it. Let’s let’s package all that up into a single archive and make it so it’s easily transferable. It’s repeatable. So if somebody wants to take that same set of applications.

They can package it up and it’s declarative. The manifest really supports this. and in the end we have made it so that it’s, it’s a lot more repeatable to deploy to air-gapped environments where typically that has always been a lot of a juggling of many different artifacts and many different problems.

Sally Cooper (04:33.275)
Wow, yeah, that context is really helpful, especially for understanding where ZARF came from and what it was originally designed to solve. And from there, it kind of naturally leads to how ZARF is applied today. I was wondering if you could differentiate when trying to solve distinct critical environment problems.

Brandt Keller (04:53.442)
I think in the way that it’s kind of like well-postured to help people and its critical function today is to be more than its sole collection and transfer processes. We want to grab the things, we want to make sure that we have everything we need because we can’t easily reach back out. We have to go back out to the internet.

Grab more things if we don’t have them. so we want to make that process as easy to use. want to be able to kind of put those security constraints on the connected side so that we don’t bring anything that we shouldn’t bring with us to an environment that is, let’s say security critical. If you’re operating in those environments in every single piece of the, you know, software puzzle is scrutinized. we want to be very careful that nothing accidentally.

Sally Cooper (05:40.496)
Yeah.

Brandt Keller (05:51.936)
malicious or otherwise makes it into those environments. so there’s a, there’s a, you know, a wide opportunity here to introduce kind of like some security gates. how can we ensure that it’s going to be functional when it gets to the critical or secured environment? This air gapped environment in particular, is, know, first and foremost, where we, want to, you know, kind of help the community prosper. but on the outside of that is, one transparency.

If you’re pulling artifacts, where did you pull them from? What are they comprised of? And again, for those who may be operating this space, you can see, well, it’s like, well, I’m doing all those things today and that’s wonderful. but you’re probably doing them with a variety of tools. You have your, you know, container image management tool. have your Helm chart management tools. have your SBOM tooling that will then scan your.

Software artifacts. So you know what they’re comprised of know what that inventory looks like. And for Zarf, we really wanted to wrap all that up and more into a single process. You create this manifest. And after that manifest is created, you do as our package create, it’s going to grab all that stuff. We’re going to be creating SBOMS on the fly for those artifacts and putting them in the package so that again, we transfer this.

We still see things burned to CDs, as well as, that may seem. And, we want to make it so that when that artifact is in the environment, it’s very, it’s very transparent. You can look at it and be what, what am I about to install? and so there’s a, I think that’s the first layer of Zarf, which is what’s package and transfer it. there are other tools that do this and that’s wonderful. We like to kind of collaborate on solving this problem.

How do we make these artifacts more portable? but then Zarf’s kind of, you know, second, would say superpower is really to enable deployment of software. so how do you know what you deployed? Where did, where did, what are its pieces? how can you work with those pieces and kind of version control them so that the kind of parts and pieces can, you know,

be sustainable and sustainability is kind of a really big part of what we want to solve. but on the outside of that, how do we do all of that without that air gapped environment in particular, having to juggle a lot of disparate or possibly insecure infrastructure. in particular, the, problem that we most often see is that when you want to operate in an air, air gapped environment, you have to bring all this other infrastructure with you.

You have to kind of stand up a registry to pull images from and more often than not, those aren’t secured with TLS because we just want to get it up and running. We want to see that it works. and so for Zarf, we really took a step back and said, how can we bring the, everything we need for the environment to operate in such a way that we’re not going to be left with these disparate puzzle pieces of, infrastructure running that could be potentially insecure. That could be hard to maintain, hard to manage and again, leaning back into ultimately not very sustainable.

Sally Cooper (09:18.49)
One thing that stands out about Zarf is that as more teams use it in real world conditions, the project itself has continued to mature. I’m just wondering in your opinion, how has Zarf evolved?

Brandt Keller (09:34.062)
I think that it’s evolved in a variety of ways, um, kind of on the, on the cusp of in the kind of the very early days, was what’s all of a very niche use case to some. And we say that in such a way that it was like, it was very much a single, uh, Kubernetes distribution, um, air gap tool. And on its onset since then we’ve kind of seen that it really does.

prosper when we look into how can this be a, you know, a tool that is very agnostic of this underlying Kubernetes distribution model, right? Now we have cloud vendors that we want to operate with air gap in the cloud. Maybe not something people always think about, but it is very prevalent. firewalls as kind of the most basic use case of kind of isolating.

cloud infrastructure from the rest of the internet or the cloud. But then we’ve got, you know, the onset of many different new Kubernetes distributions being released, many different problems to solve where you just want to be able to transfer files and maintain, maintain state on those. And so we kind of see the evolution of, you know, taking what we’ve always wanted to solve, which is to make the transfer and deployment process easier, and then integrating the rest of the ecosystem around that.

people came to us and were requesting, you how do we integrate the GitOps ecosystem with Zarf? And how do we make it so that, you know, the mutation model, which I won’t go into unless people really want to hear about it, but how do we make it so that when some of the underlying magic is happening, that, you know, hey, that’s a really great thing, but that’s a cool pattern. Could we apply it to, let’s say, GitOps and Git?

And, you know, kind of stepping back and being like, yes, yes, we can, we can make it so that rather than it being, rather than it always being a process in the air gap where you have to transfer the artifacts and then change a bunch of references so that they point to the right place in your new environment. What’s, what’s kind of handle that for the user, let’s make it more of a, you know, nice and consolidated user experience. so it’s evolved in that way, as well as, know, kind of.

as it relates to the OpenSSF, trying to make open source software more secure.

Sally Cooper (12:21)
Love that. the mutation model, I do think we’re going to need a part two for that because now I’m super curious. But with the evolution, it’s especially interesting when you zoom out and you think about software supply chain security. You think about the broader ecosystem. Why is this a good fit for OpenSSF and how does Zarf help secure open source software?

Brandt Keller (12:30.52)
That is one of the most fun parts of my job is to really try to find new avenues, right? Zarf on again, stepping back a little bit to the early days, it’s been software integrators. They want to take software from its source. Usually these are open source projects and they want to package them up and take them to their environments.

But there’s a real like key opportunity that we’re seeing manifest here really within the last, I would say year and even last couple of months where like Zarf’s transparency models, Zarf’s packaging mechanism could be a key enabler for how software consumers look at open source projects and kind of deem, you know, how well are they doing software like supply chain security?

There’s going to be some of these like onset, I’d say issues where again, maintainers of projects, whether they’re sponsored by a company or whether they’re doing it out of their free time, because they love the technology. they only have so much time in the day. And, you know, I think supply chain security, it’s evolving quickly and it’s continuing to evolve. And most of the time that asks maintainers to do more things, right? Initially you were developing an application.

And you’re saying, Hey, it’s free for everyone to use. I’m not, I’m not asking anybody to pay me to do this. and that’s great. And then more people are like, Hey, for supply chain security, I really need to know what the SBOMs look like. Can you add SBOMs to your releases? Can you sign your releases? And you can kind of see each one of these layers is now a new cognitive burden for, maintainers to kind of normally manage, then

They have to manage the processes on top of like performing that activity. so, I kind of, see some like very distinct opportunities where. If the goal is to help secure open source software, we can really do that by using kind of like Zarf’s declarative manifest model in order for upstream projects to produce releases that consolidate all of that burden again into.

Brandt Keller (14:54.294)
A declarative manifest that they orchestrate in their pipeline, just one, one command, right? Hey, let’s do as our package create. And it’s going to create my, everything I need to run an application such as guac, for instance. we’re working with GUAC on kind of this problem statement. and it’s like, there’s some very fascinating opportunities where you’re going to have everything you need to run GUAC. You’re going to have the SBOMs for GUAC. You’re going to have.

You know, the ability to have that release artifacts signed. And so if you go back to that software integrator, they typically have wanted to deploy GUAC. would create their own Zarf package and pull all those artifacts. Well, now Zarf could just, the integrator could just do a Zarf package poll and they would have everything they would need. And they would know that it’s coming from the upstream source. They would have the confidence around it. They could check the signatures, review the SBOMs and kind of.

you know, kind of look at the posture of, Hey, everything I’ve needed now is kind of consolidated into a concise workflow.

Sally Cooper (16:05.62)
Alright, Brant, before we wrap, it’s time for Rapid, Rapid Fire. These are questions I’m going to ask you, you’re going to answer without any overthinking. No explanations, just your first instinct answers. Are you ready for Rapid, Rapid Fire?

Brandt Keller (16:32)
Let’s do it.

Sally Cooper (16:34)
Star Wars or Star Trek.

Brandt Keller (16:35)
Star Wars.

Sally Cooper (16:36)
Solid. Favorite retro video game?

Brandt Keller (16:41)
Oh, uh, Spyro.

Sally Cooper (16:46)
Ooh, nice. Marvel or DC?

Brandt Keller (16:49)
Marvel.

Sally Cooper (16:51)
Excellent. All right, and last one, favorite open source mascot?

Brandt Keller (16:56)
Oh, not counting Zarf?

Sally Cooper (16:59)
Zarf, of course, after Zarf?

Brandt Keller (17:03)
Um, probably Golang Gopher.

Sally Cooper (17:08)
Oh right, I have that one too. And Zarf is really cool. I love that. All right, perfect. No notes. As we wrap things up, what’s your call to action for our audience? If someone’s listening and wants to learn more about Zarf, try it out or to get involved, where should they start?

Brandt Keller (17:25)
They should start as a Zarf.dev, short and sweet and kind of take a look around and really what we’re trying to understand is, you know, what are the needs of users in different critical environments? I like to visit the public sector groups in a variety of different foundations to see kind of what problems they face, because most often than not, the most constrained regulatory environments are the hardest ones to solve for because they can’t rely on the internet or they have additional scrutiny and we really believe that Zarf is a a great avenue to evaluate and understand. And if it’s not, we’d love to hear from you. Like why, why not? And what are the things that we could do to improve?

Sally Cooper (18:10)
Brandt, thank you so much for joining us today and for all the work you’re doing to help secure how open source software is delivered into some of the most challenging environments. And to everyone listening, happy open sourcing and that’s a wrap.