 Hi, this is the host of Nibbārthi and today we have with us Jim McGuardia, co-founder and CEO at Nirmata, Jim. It's great to have you on the show. Thank you Swapna. Great to be here. Since this is the kind of first time we're talking to each other on camera, so I would love to know a bit about the company itself. Tell us, you know, what is Nirmata all about? So Nirmata is in the Kubernetes governance and operation space. So as you know, today containers have become the de facto way of packaging any application and Kubernetes has emerged as the, you know, a container orchestrator of choice across data center, cloud and edge. But as more and more clusters are being deployed, as more, you know, developers, operators, security teams are using Kubernetes, what we learned working with customers is there's a need for strong governance and policies across the enterprise. So that's what Nirmata does and provides for its customers. Nirmata was created almost at the same time or before, you know, Kubernetes was officially announced. It was the early days of, you know, containers as well. How much have you seen the space has changed because, you know, you predate a lot of these technologies, so the company itself has evolved, but you have also seen the evolution there. So talk about that. So certainly a lot has evolved in the space, right? So when we started, of course, containers were still people were questioning why containers versus VMs, you know, those sort of questions are, of course, all gone away today. And as, you know, Kubernetes, at that time, you know, there were different orchestrators, like even Mesos, Swarm, but Kubernetes has emerged as the standard and as the choice across the community, right? So now that all major cloud providers, all infrastructure renders have supported Kubernetes, the community is very strong. And we're seeing more and more enterprises adopt Kubernetes as their choice. Now, once again, you're talking about the evolution of, you know, the whole, the way we write, run, deploy, manage applications. When we look at cloud, cloud native, cloud native is more of a kind of process, or it's not a, it's not a thing, it's not a place, it's a way of doing things. So can you also talk about how has the rule of policy and governance evolved in the cloud native space? And also if you can also kind of specifically, what is, it's important to the Kubernetes world? Right, yeah, great questions, right? So first off, Kubernetes is one of the first platforms that was designed for the DevOps era, right? So it brings together concerns, not just of the developers, but also of the operations team, the security team. And of course, the whole goal of adopting Kubernetes and containers is agility. You want to give developers the freedom and the flexibility to deploy code faster, to be able to push to production. But how do you do this and still keep centralized visibility, to centralize policies and enforce those organizational compliance requirements? So that's where policies come in. And to your second question, in terms of how policies have evolved, if you take policies and kind of marry them with cloud native, what we believe the right way to solve this is with policies that are native to Kubernetes. So if we love Kubernetes for deploying configurations, why not use its extensible API to make policies native to Kubernetes and use all the same tooling, all the same goodness like GitOps, everything else we are doing for Kubernetes, also to manage policy as code across multiple clusters. When it comes to policies, governance, what is the state today? How many people are aware of it? When you look at this, are you still in the face where you still have to do a lot of education, awareness about that? Are you in the face of, hey, people are already in the maturity curve and we just have to help them in their journey? Great question, right? So I am also in the CNCF. I'm a co-chair of the policy working group. And within the CNCF, our charter is to promote awareness of these key fundamental technologies, like policies. So more and more people are recognizing that once they put Kubernetes into productions, policy are as essential as networking storage and other security concerns. And within the CNCF also what we've seen, besides Kiverno, there's also OPA gatekeeper as a project, which is a policy engine. There's other policy engines being built. So there's growing awareness about this need and for good solutions to solve and to address the concerns here. Now, let's talk about project itself. So the Kiverno project has moved to CNCF incubator phase. So first of all, talk about Kiverno project itself. Then let's talk about what does moving into incubator actually mean? Right. Yeah, so Kiverno emerged as a module in the Nirmata governance and operations platform, and we open sourced it about a year and a half ago, and we donated it to CNCF. So since then, the community has grown almost 500%. We've reached about 260 million image pools of Kiverno, which has kind of exceeded our wildest expectations in terms of the project growth itself. But just seeing the download, seeing the community grow is not enough for incubation. Incubation in the CNCF journey, there's three phases. There's sandbox, there's incubation, and then graduated. Projects, of course, like Kubernetes itself and Prometheus are graduated because of their maturity, because of their large adoption. So Kiverno started as sandbox, but to get to incubation, you have to prove not only is there a need for that solution, but there's production users who can vouch for it, who have deployed it and are solving very key use cases for their businesses with that project. So those are some of the due diligence things we have to go to, and then the Kubernetes Technical Oversight Committee votes on this, and it requires a supermajority vote to go from sandbox to incubation. In most cases, especially when you look at company like Nirmada, most of what that you folks are doing is that there's already a user base, you are releasing it into an open source. So what is the situation with Kiverno here, how mature it is already? So look, the term incubating, and Kubernetes was graduated after a while, but people are using it in production. So what I understand is with Kiverno also, how mature the project is, is it already being used in production? And if yes, what kind of use cases are you seeing there? Yeah, so certainly what we're seeing in the community is that there are, like I mentioned, already production users who have to give their votes to the Technical Oversight Committee for Kiverno to get to incubation. So today, we are seeing thousands of users deploying Kiverno in their clusters. The types of use cases we see are starting from security, where things as you might know, pod security got deprecated in version 1.22 of Kubernetes. It was removed in version 1.25. And what, you know, Kiverno becomes an alternative for fine grain control of security at every level of your workload, starting from pods to other workloads, as well as being able to automate concerns across developer and operation teams who are managing the cluster. Let's also go a bit detail into Kiverno and explain what exactly does it do, how it helps, you know, for second users. Right. So Kiverno runs inside every Kubernetes cluster and it acts as an admission controller. So what that means is in Kubernetes, as different components are communicating through the Kubernetes API server, Kiverno has the ability to inspect each API request and validate configurations or mutate configurations or generate new configurations on the fly. So this creates a very powerful set of use cases for security and automation, including things like software supply chain security where you can sign and verify container images. You can check for attestations and provenance to make sure your images are coming from a trusted source. Even for example, for checking for vulnerability exceptions and allowing only images with, you know, certain exceptions into your cluster. So extremely powerful and rich set of use cases. We have over 200, you know, sample policies in our community library and growing rapidly. Can you also talk about, of course, it's an incubation phase. What is the process for it to graduate eventually? Do you have something in the mind? And what does graduation really mean for users? Because as we discussed earlier, that most of these products are already in the production. Right. Yeah. So certainly, you know, like we were talking about, you know, the production adopters even at the sandbox phase at the incubation phase. It means that that has CNCF's vote of confidence to say that this project is critical to Kubernetes and should be used in production Kubernetes clusters. And the graduated phase really becomes, you know, it's more of a matter of time and scale where you are kind of proving other performance criteria, other scalability criteria. And you have a big enough community for the project itself. Earlier, we were talking about there are other projects also about policy management. Can you also talk about, you know, what other projects are there and how does, you know, Kiverno kind of either complements them or offers more benefits to users with these projects? Right. Yeah. So some of the other projects for policy management are, like I mentioned, OPA Gatekeeper, which has been, you know, it started about one or two years ahead of Kiverno. So that project is based on a technology called Open Policy Agent, which uses a language called REGO for authorization and for policies. So the challenge with that that users have faced is they need to learn an external language and they have to manage policies using that language and, you know, author policies in that. So Kiverno, on the flip side, is designed for Kubernetes from the beginning. It doesn't require learning any new language. It uses Kubernetes's declarative configuration management for policies. And it also, you know, the policy reports as well as the other aspects of Kubernetes, it fully understands and embraces all of those patterns, those idioms to make it very simple to manage policies in Kubernetes itself. So that's the primary differentiation. Another major differentiation is Kiverno policies are not just for security, validation, and blocking configs, but they can also be used to automate various configurations, right? So when a namespace is created, for example, in Kubernetes, to automatically generate network policies, to default secrets, role-based access control primitives, all of that can be automated through Kiverno, which is extremely powerful for security, as well as operations teams. What kind of community is there along this project? Now, Kiverno is a very strong end-user community, right, which we're very excited and proud about. Most of our contributors tend to be end users versus vendors. So we see very much real-world use cases, and these end users range from, you know, in the 5G space, you know, folks like Vodafone and Deutsche Telekom, and these are public users. These are folks, you know, who are active on the Kiverno contributors list, as well as in the community. In the enterprise space, we see large financials like Bloomberg, so very diverse, very growing, and of course, there's several, you know, hundreds of smaller users and overall thousands of deployments where we are seeing Kiverno being adopted. What kind of roadmap you have for the project? What are the things that are in the pipeline that you are working on? Yeah, so extremely active roadmap, one of the, you know, features that we have collaborated with a team from IBM labs, research labs in the building is, you know, for YAML signing and verification. So basically the idea is not just to secure your container images, but using Kiverno to sign and verify YAMLs itself. So, you know, secure like the certain configurations cannot be tampered with for security reasons within the cluster itself. So that's one feature we're also coming up with other, you know, performance improvements in terms of further scalability for Kiverno. We also have, you know, OCI registration which is coming in or, you know, integration with using OCI registries to store Kiverno policies, right? So several exciting features and we're constantly like adding to our roadmap based on end user requests as well as needs. Jim, thank you so much for taking time out today and talk about the project, talk about the company and also, you know, talk about the larger problem which is there in this evolving market in the evolving phase when it comes to policy and governance and sharing the whole journey which predates Kubernetes and containers so thank you for sharing those insights and I would love to have you back on the show again. Thank you. My pleasure. Thanks for having me, Sutner.