 Hi, I'm Subhan Parthia on behalf of the Linux Foundation and my next guest is Kapil Thangabellu, lead maintainer of Cloudcoastodian. Kapil, it's great to have you back on the show. Happy to be back. We are going to talk about CNC of Cloudcoastodian. So can you talk about how are you involved with the project? I founded the project maybe four and a half years ago when I was at Capital One and had been leading in the open source since April 2016 when we first released it to GitHub. So I'm currently the lead maintainer for the project. We have a group of about a dozen maintainers and over 300 contributors today. And now let's talk about the Cloudcoastodian project itself. What is it all about? Cloudcoastodian is designed to give a policy as code tool for large organizations or any organization really that's operating in the cloud. The challenges of cloud governance really go across multiple different pillars with regards to security, with regards to compliance, with regards to operations or cost optimization. And these are sort of all the things that need to be well managed in the cloud. And so what Cloudcoastodian does is it gives you a YAML DSL for being able to express policies that then are enforced in an environment. So a policy typically involves three parts or four parts. One is it defines a resource that you want to enforce a policy on, say a VM instance. And then it applies some filtering to the collection of instances to find the things that you're interested in. Say instances that have underutilized CPUs or instances that are on the public internet and don't have appropriate IAM permissions associated to them. And then it lets you take some actions. And so those filters and actions are really fine grained and you can compose them sort of in arbitrary ways. And the actions might be something like stop the instance, take a snapshot, modified security groups or IAM capabilities. And then finally there's this notion of a mode, an execution mode. And so an execution mode basically defines how you want to run the policy. The default one is just simply pulling and you can pull the clock control plane for information about those resources to find and filter to the interesting set. But the more interesting ones are also event based where you're actually able to express that this policy should evaluate things in real time as things are changing. And so you can do that on sort of the API audit stream of the different public cloud so that it affect able to enforce policy in real time as things are changing in your environment. And those event bindings can take place across dozens of different sources. We have deep integration with say AWS config or with GuardDuty or with Google Cloud Security Command Center. So there's different signals there. API audit streams are probably the most common one that people use. But you also have additional sources both from first party from the providers themselves as well as downstream integrations. If I'm not wrong, the project was contributed to CNCF in 2020. Why did you decide to contribute the project to CNCF? And then we'll talk about the governance and everything of the project itself. So we had a lot of contributors from the different cloud providers from Microsoft, from Amazon and then a large end user community in Capital One, TransAmerica 23andMe. We really have a very diverse set of contributors. And the notion on moving the project to the foundation was trying to find a good neutral home where all these diverse collaborators could work on the same project and feel safe that the project was in good stewardship, had good governance that it wouldn't have had that neutral home to continue to receive continued investment and adoption from other users. And a lot of this was notionally geared towards wanting to become a de facto standard for cloud governance. And we felt like the best way to achieve that was to have a neutral home for the project and its collaborations to live in. You already explained that a lot of companies involved, initially you also mentioned what kind of communities there. I also want to know about the governance structure. The good thing is with most Linux Foundation project there is a very good structure, how the project is governed, but sometimes projects choose their own structure. So talk about the governance of Claude Custodian. So the Linux Foundation I think is in the CNCF are fairly famous for not actually dictating. So we had considered Apache as well. I think the challenge that we saw with the Apache Foundation and all hats off, it's a wonderful organization. But it's very prescribed with regards to how things must run and everything and that tends to involve a lot of communication overhead. With Linux Foundation and the CNCF in particular, they really don't dictate to a project what governance structure should be outside of it should have one. I think is the most important thing that they consider. So currently we're closer to a BDFL type of model that you know that style has sort of fallen out over time. And we're currently sort of looking at whether or not we want to institute that as a rotating structure over time and have going through a maintainer election process to elect that. Right now from a governance structure, we also sort of carve out to the different providers. We have a lot of different like no one can know all the clouds to speak. And so we have very deep integration capabilities with with the three major public cloud providers. And so right now it's also a sort of a sub maintainer or project maintainer on a on a subtree sort of model with regards to people that are able to freely code review and commit on different projects. So we have a team at Azure that's been working on our Azure provider for a number of years. And so they run fairly independently with regards to be able to manage and triage on those issues that affect that threader distinctly. This is an open source project so anybody can go and check it. But if I ask you what kind of roadmap you have or what kind of the next big thing for the project if you can share those. Yeah, so we've gotten a lot of different capabilities right now on to the different cloud providers. So some of this one of the largest challenges for a project that's tracking to native capabilities on the cloud is simply keeping up with the pace of innovation of the cloud providers. And in some sense that is that is a key value chain for why open source is so key in this space is that it takes community to cover on all of these different capabilities. A recent last maybe a year and a half ago I built out a website adbsapichanges.info simply just to keep track of all of the API changes that were happening within a single cloud provider. And you know there are literally dozens of them each week covering off on a diverse array of services. So one of the key focuses for the project is to always continue to track that pace of innovation from the underlying providers and make sure that that's reflected in capabilities within custodian such that people can govern on these newer features capability sets. So that's a key focus area the secondary capabilities are really about going into, you know, keeping track with and doing deeper integrations with some of the native capabilities on the provider. So there's new features and then there's the capabilities that the cloud providers themselves have in this space with regards to governance and and one of the key differentiators for custodian is that we actually do deep integration with those capabilities. So we want to be the easiest way for users to use the native capabilities using custodian to help get more productive workflows. As an example, let's take AWS config and AWS config rule might be, you know, 50 to 100 lines to write a custom rule, and then there are 50 to 100 lines to do the DevOps around that. With custodian, you can simply do that roughly 10 lines of the animal and get something that is functionally equivalent and is a 20 x productivity game. So making sure that we cover off on those capabilities. I think there's some newer capabilities on both the Azure side and and the GCP side that we'd like to continue to grow on. We've had some experience with some users operating at large scale within Azure and GCP and some there's some new capabilities there with regards to I don't need that we want to expose. And then finally, you know, I think there's a notion of, you know, now that we're in the CNCF being able to add additional depth to our Kubernetes integration. It was originally done as sort of a proof of concept, and it, you know, it works, but it's very if you look at what state of the art for tools in that in that particular space and that compute provider that that we need to evolve there to be to be a best of breed tool. Appeel, thank you so much for taking time out today and talk about not only Stanley, but also claudka student. And as usual, I love to have you back on the show. Thank you. Thank you.