Project Lightning Talk: Beyond Guardrails: Resource Lifecycle Automation With Kyverno - Ammar Yasser

This talk covers the capabilities of Keano, a policy engine designed for Kubernetes and YAML. The speaker discusses how teams traditionally use Keano to block bad configurations and highlights its newer features that extend its functionality beyond simple validation. Using the example of namespace as a service, the talk explores how Keano can automate the creation and management of ephemeral namespaces, including resource generation and cleanup processes. The speaker highlights three new policies introduced in version 1.17: mutating policies for resource compliance, generating policies for creating associated resources, and deleting policies for automated cleanup based on time-to-live (TTL) settings. Overall, the emphasis is on how Keano serves not just as a guardrail, but as a comprehensive platform automation tool.

Yeah. So, hi everyone. Yeah. My name is uh Luke Mowski. Um I'm a maintainer for Keano and today I'm stepping in for Amaya sir who worked on that. Sadly could not come to CubeCon so yeah I'm replacing him and um I'm going to explain to you how like most teams use Keveno for blocking bad configs basically. Um but since the latest updates uh Keveno can do far

more than just blocking stuff. And uh to explain all of that I will use um namespace as a service as an example. So the examp the the problem we have is um we like namespace as an as a service sorry uh you want to create ephemeral namespaces uh to test your pull request right so you create namespace uh but you want as a platform engineer you want

to follow all the best practices as well as creating intermediate resources and maybe clean up when the pull request is done. Um, and the natural solution to do that will be to use a custom controller, you know. Um, so it will watch name spaces and do what we just talked about. But, um, in the end, you're going to have also to make it scalable depending on your

infrastructure, monitoring it, probably adding reporting and all of that on the long term uh, becomes a real uh, engineering tool, you know. So, this is where Keano comes in. Um, Kano for those who don't know is a project um like a we are a policy engine based on YAML and cell and what we do is we handle as I said validation but we handle much more things

uh than that uh on top of that it comes also with integrated reporting uh fine grain exceptions and uh basically it's built for Kubernetes but in the recent versions we've been working to to get it out of Kubernetes for authorization and for other stuff like that as well. Um, so I was talking about the new policy. The first one we introduced in 117 uh like made made

stable in 117 was the mutating policy. Um, basically it's here to mutate your resources before they eat etc. So the cubernetes database and uh what's going to do is like it's going to change everything uh to make sure it complies with your uh requirements. Um those policies those policies will allow you as well not just to mitate the name space that was created but all the underlying

resources as well. Um so this is a big plus compared to some other policies like native policies in cube and things like that. Um, another policy that we introduced is the generating policy. So, we talked about generating resources like network uh policies, world bindings. Uh, this is the policy you want to use. Um, basically what's going to do is going to create all the resources you told

him to when the namespace is created and once it's done um everything is going to be related to that policy. So, if at some point you delete the policy or update it, all the resource will be deleted or updated as The last one we wanted like in our example was cleaning up. Once the pair is merged, you want to delete everything after some time. Um this policy

is going to be like the deleting policy. And um we can for example implement a TTL kind of behavior where we say the namespace has a TTL and just delete like run every hour and delete it. Um basically it's going to automate like a kind of cleanup chron job creation. uh instead of you doing it yourself and just with that uh the life cycle of our policies

is complete. So now we have three YAML policies that you can put in your GitHubs pipelines in your um GitHub repositories that you can audit um instead of a controller uh where everything is baked into the code and um yeah it's just that it shows that Kano is just not for guardrails but it's really a platform automation tool and you can use it to do really complicated

So thanks for listening and everyone uh there is the Kanukon this afternoon. So if you want to join feel free. Uh we'll have a talk similar to this but more deeper. I didn't show you any code or anything because of the time. And uh thanks for every maintainer here present uh want to support me and to to uh talk about that to maintain the project. >> Awesome.

Thank you Luke for coming filling in.