 So, welcome everyone. We're going to talk about Kubernetes Policy Management with Kivarno. So, quick introductions. I'm Jim Baguadia, a maintainer of Kivarno. I'm also a co-chair of the Kubernetes Policy Working Group, a track lead in the multi-tenancy working group and a co-founder at Nirmata. So, there's quite a lot of topics I would like to cover. So, just in terms of logistics, I will be answering questions on the Slack and on the message channels. So, we'll try and save time for questions, but if we run out of time, we'll be on the sessions itself. So, we'll start out by describing why we need policy management for Kubernetes. We'll talk about why Kivarno matters. We'll go deeper into the Kivarno architecture as well as what Kivarno policies look like. We'll talk about how you can do some complex processing logic with Kivarno in Kubernetes, how it can interact with external data sources, and go into other features of Kivarno itself, including reporting metrics and some advanced topics. So, let's get started with why policies matter to Kubernetes itself. So, first off, we've all seen the headlines and the security-related incidents where Kubernetes configurations and misconfigurations tend to be the leading cause of incidents that we see in clusters in production. Also, I love this tweet from my actual Kubernetes admin where they have tried to deploy clusters without policies, and very quickly they see, of course, if it's a shared cluster, you have many development workloads, there's dangers, there's issues bound to happen. So, policies serve as a contract between the different roles, between the different personas in Kubernetes. So, you have developers who want to, of course, deploy their applications, manage workloads, you have security folks who are trying to make sure that the right security configurations are specified in every workload, in every namespace, in every pod, and then you have the operations team responsible for managing clusters, managing the shared services. So, policies bring all of these roles together, and really it's an enabler of DevSecOps at scale. So, what policies can do for you is improve the overall security posture, get rid of misconfigurations, give you proper separation of concerns between these DevSecOps roles, reduce the overall configuration complexity, and also help promote best practices. Your developers are perhaps not too familiar with all of the details about Kubernetes workload configurations, policies can help with that too, and lead to more self-service, more automation. All right, so let's talk about why Kiverno and what the motivation for this project was, what some of our goals are. So, with Kiverno, we use the tagline in a Kubernetes native policy management. But does it really matter to be Kubernetes native, and what does that even mean, right? So, a lot of vendors, of course, a lot of products claim to be Kubernetes native. So, it's important to kind of dive in a little bit deeper. So, when you think about it, there's several levels of perhaps being Kubernetes native. So, the first level is just being focused on that as a domain, on, you know, targeting Kubernetes or Kubernetes users as your audience if you're a vendor or if you're developing a tool or a solution. So, that could also be called Kubernetes native, but that's not quite enough. So, the next level up is where you start actually interacting with Kubernetes APIs, and a lot of tools do this as well. Another level up is when you actually operate your solution or tool as an operator in Kubernetes, and you're expanding or you're extending Kubernetes APIs itself using custom resources and custom resource definitions. Another level above that is if your solution really understands Kubernetes patterns, Kubernetes idioms, how pods and pod controllers interact, what an owner reference means. So, you're going much deeper into how Kubernetes works itself, and your solution becomes part of the control plane in Kubernetes. And finally, level five or the highest level of being Kubernetes native here would be if your solution can automatically adapt to new Kubernetes schema, new solutions coming in, and as these things change itself, being able to talk to the API server. So, Kiverno is designed to be completely Kubernetes native. It is only focused on Kubernetes, which is, you know, some of the earlier levels, but it also interacts with the API server and can, you know, read the metadata of the schema for every Kubernetes object, including custom resources to be able to adapt policies to that. So, this provides a lot of flexibility, a lot of benefits, and simplifies writing policies, managing policy definitions. Because if you don't understand what Kubernetes APIs are, what the constructs look like, of course writing policies is going to be a lot harder, and you have to develop a lot of common solutions just to get started with those things. So, one other question that comes up in terms of why Kiverno is, well, what about OPA Gatekeeper? That's a fairly mature project in CNCF. It's also, you know, like Kiverno, it's a CNCF project. And, you know, there's a very good community and focus on it. So, there are several, you know, comparisons out there. So, I encourage everyone to go, you know, do a quick search and you'll see this is from Victor Farik, who's at UpBound. He's done a great video on Kiverno and, you know, OPA Gatekeeper. There's another one from Chip Zahler at Dell. He's written a series of blog posts on comparing the two solutions. And really the difference comes out to what is it that you're trying to achieve? What are you trying to solve with your policy management and focus on Kubernetes, of course, right? So, in terms of feature-wise comparison, both tools stack up well. The major difference to me is in how you manage policies, how you declare policies, and use Kubernetes, you know, policy management in your teams and organization. So, here, you know, we're comparing the same policy written in Rego, which is the language that OPA uses. OPA is Open Policy Agent. And compared to Kiverno, which uses a more declarative style of configuration, which is native to Kubernetes. It's, you know, again, if you understand what a pod spec looks like or what a deployment looks like, Kiverno policies seem fairly natural and understandable, right? So, it's all about simplifying this to be able to, you know, adopt policies at scale and promote these best practices itself. So, certainly, you know, if you're kind of familiar with Rego, if your teams have developed expertise, OPA is a great solution, and Gatekeeper, you know, fits OPA into Kubernetes. And if you also, if you're trying to, you know, manage policies across different systems, not just Kubernetes, but let's say you want to write policies for your microservices app, things like that. OPA is also a good solution for that. But if you're kind of trying to solve security and automation and other concerns just for Kubernetes, trying to evolve from a DevOps team to a DevSecOps team, and your focus is Kubernetes, Kiverno comes out to be a much easier solution to adopt. And that, you know, is across all of these different roles. And it scales also a lot better as your teams grow and as your Kubernetes usage grows itself. So let's talk about some of the use cases and what we're seeing the community solve with Kiverno itself, right? So starting with the basics, of course, pod security, workload security, Kubernetes has some built-in constructs for pod security. The pod security spec has been, you know, our pod security policy has been deprecated in one, two, two. There's a replacement being worked on, which will do, you know, pod security at the namespace level using labels. And that is planned for 1.25. But there's a lot more required to configure security for your workloads. And even in pod security, there's a lot more flexibility, production deployments typically require. So definitely check out, you know, Kiverno or OPA for one of that. But you need to make sure that beyond pods you're also securing your services, your namespaces, other things like your role definitions, even CRD definitions in Kubernetes itself. Then promoting best practices, right? So configuring probes, configuring health checks, making sure that your RBAC is automated and as fine-grained as possible, having multi-tenancies. So sharing clusters always remains a big challenge in Kubernetes. How do you do this securely? How do you make sure you're avoiding the noisy neighbor effect, right? So those type of things can be very well, fairly easily solved and there's some common examples and policies available to do this in Kiverno. Also auto-labeling, proper hygiene in terms of how you're managing these resources, making sure your configurations, you know, are generated and again limited to the scope. And one new use case we have just introduced, which if you have time I'll do a quick demo. Otherwise, you know, there's links in a post I can share of it show this. But even verifying, you know, image signatures for containers at admission controls. So making sure that when a container is deployed, that you have a signed image and you are, you know, using that only if it's been signed and you have the proper attestations for that container image and you can verify it against a bill log. All right, so let's talk about the Kiverno architecture and how it works in Kubernetes itself, right? So I'm going to go back here to some of you may know the exact mole definition for, you know, this is extensible authorization using XML. And, you know, Kiverno, of course, has nothing to do with this, but the reference architecture for policy management that was defined in this OSS standard applies. So here they introduced terms like a PAP, which is the policy administration point and then a policy enforcement point and then also decision points and information points, right? So this is a pretty good, you know, high-level architecture to use for policy management. And, you know, we can now map this to what happens in Kubernetes, right? Because in Kubernetes, every request flows through the API server. It goes through an authentication phase and authorization phase. And then it goes through admission controls which are extensible. So in this admission controls, you have a chance to mutate, validate, generate, and do other sorts of interesting things, which is really where Kiverno will fit in as you'll see. But now mapping these two together, let's say you want to have a policy enforced across your clusters, your fleet of clusters, and your CI CD pipeline that says pods should not be run as root user, right? So now you can declare that in your PAP, in your administration point. And keep in mind this could be a GitOps controller, this could be, you know, other tools that you might use, you know, to manage your fleet of clusters. But once you define that policy, it should be applied in your CI CD pipeline. So you're validating your YAMLs, you're validating that, you're generating the right image signatures. And then that same policy can be auto-generated and also applied, you know, in your, across your fleet of clusters. And since with Kiverno, a policy is a Kubernetes resource, it's easy to deploy, easy to manage that within each cluster, again, using standard tools like kubectl, customize, GitOps, best practices like that. So a little bit more detail. So if you kind of look underneath the covers and how Kiverno works. So there's multiple controllers, which run all as a single, you know, workload. And they register, Kiverno automatically registers itself as a web book. So like we talked about, it can receive both mutating as well as validating a web book, you know, requests. And then there's based on various policies that you write, which Kiverno maintains in memory as a cache of policies. These will be applied dynamically and you can either trigger the mutation of resources, you can trigger the automatic generation of resources, and also validation of resources. So if you want to block or enforce, you know, any policy based on, you know, things which are going on. So if you change any of this in real time, Kiverno will automatically update. It also does a background scan on all existing resources and will show, you know, those results as well. So it's very easy to now fit in these policies as Kubernetes resources, manage its scale, and just like you would with your workloads itself. So another kind of view of Kiverno itself is if you look at the deployment architecture. It looks something like this, right? So each Kiverno install, we can have multiple instances, multiple deployments, which run as a replica set underneath, and that will spin up and manage the pod life cycles. And then Kiverno has a bunch of other constructs like the web book definitions that creates, also like, you know, custom resources that get installed and manage either through the Helm chart or through the YAML files if you're installing Kiverno. All right, so in the next section, let's look now at Kiverno policies, right, and how a policy itself works. And we'll start with some simple examples and then also look at some more advanced features for managing complex logic in policies. So each Kiverno policy contains a set of rules. And before those rules are applied, there's a match and exclude block which will get executed with, you know, against an incoming resource. And that resource is contained in an admission request created by the API server. So Kiverno first, you know, goes through the match exclude and if that, you know, passes, it will then apply, you know, the rule which you have defined. And each rule can either mutate resources, which happens in that mutating web book, can, you know, do things like verify images. And verify images is interesting because it both mutates as well as, you know, validates and the resource itself because it replaces the image tag with a digest to make sure that your image cannot be changed at runtime itself. And then there's a validation phase. So this happens after the API server validates the object, the resource that's commutated against the schema definition. And then finally, in the background, Kiverno can also generate resources. So this is extremely powerful because, you know, you could have scenarios where you create a namespace or you, you know, label a namespace and you want to automatically generate either completely new policies for that workload or you want to generate things like standard objects like network policies or role definitions. You can now easily automate this, you know, using Kiverno itself. So this is what a policy looks like, right? And again, you know, it's fairly, it's designed to match what a Kubernetes pod would also kind of pod definition would look like. And this policy is very simple. All it's doing is looking in the metadata and it's checking for a particular label to be configured on that pod spec itself. Now, one other cool feature in Kiverno is if you define this policy on a pod, Kiverno can automatically generate rules for pod controllers. Again, because it understands Kubernetes, it's designed to work in Kubernetes, it simplifies that and you don't have to manage different policy rules because the structure of pod controllers is different. This will just be handled natively in Kiverno itself. So this is another example of a policy. It's a validation rule and this policy is again extremely simple but very powerful. So what it's checking for is certain resource types and if it matches, you know, if the request, the admission request matches that resource type, Kiverno simply denies the request. Now, why would you want to do this? And the main use case here that we're showing in this policy is API objects get deprecated in Kubernetes and as they're getting deprecated, how do you know, let's say you have production workloads, how do you know where those are running, which ones need to be updated and how do you inform your developers about that? So Kiverno solves this problem because you can now roll out a policy like that as an ops team and your users will get informed with the policy report that Kiverno generates in their namespace, so which tells them these are violations I need to fix before this API construct gets deprecated. Here's an example of a mutate policy, right? So this actually changes an object and there's some simple examples here. We're just looking for a specific name of a port and replacing it with a certain port number in the first example and the parentheses are actually, you know, showing some of the flexibility in Kiverno to do conditional logic. So this is doing an if statement and saying if the name is secure, then I want to set the port to something. And the other example which has a plus sign in front of it is a very simple declaration to show that if it's not specified, then set the default, right? But if it's specified, leave it alone and let, you know, take the value that's specified. Of course you can kind of make this as complex or as, you know, involved as possible. You can even do things like match with operators, other logic that you want to combine here. Here's an example of a, you know, very popular, you know, generate rule, right? So when you create a new namespace, you always want to set a default network policy for the namespace and this rule is helping do that. And again, it's very simple. It's like less than, you know, 10, 15 lines of YAML. It's very powerful because what it does is anytime a new namespace is created, you get a default deny network policy and then your developers can add, open up the ports, open up the routes that they require for their workload, which is a much better security, you know, kind of best practice versus just allowing all communication even within the same cluster or communication to the API server by default. Here's an image verification policy, right? So this is an integration with Cosign and there were some sessions, you know, earlier, I think there was a session yesterday that Dan did from the six-storey team on Cosign, six-storey and a bunch of other tools for supply chain security. And what Kiverno does, so Kiverno, think about it as the last mile before your pods are getting, you know, run in your clusters. So this, what this rule is doing is it's matching an image pattern and based on that image pattern, it's saying that every container image has to be signed with this public key. So extremely powerful and, again, very simple to kind of, you know, do with Cosign and Kiverno and start, you know, moving towards, you know, there's a framework that Dan covered called Salsa or SLSA, which talks about supply chain security and this, you know, gets you up to, you know, a level in terms of at least being able to make sure that your image is assigned and verified before they're deployed into your clusters. All right, so let's look at some more complex examples, right? So these were fairly simple to start out and the reason why I wanted to show this is one thing that comes up against Kiverno and if folks are comparing it to something like OPA or Gatekeeper, well, OPA is a full-fledged programming language, right? So you can write very complex logic, but Kiverno has a lot of power in a very simple and easy to manage format as well, right? So one, you know, one thing that you would want to do as you're managing policies is you want to externalize data from your logic. So just like in programming, you always have data and logic and it's nice to separate your logic or your algorithms from the data. Similarly, when you're writing policies, you want to make them as data-driven as possible and decouple your data from the processing logic. So Kiverno supports multiple ways of substituting data within policies. One easy way is to use something called reference variables and these are just, you know, follow like a Unix or Linux style path syntax and you can reference other things in your policy or your resource definition itself. So a very simple way in here we are showing how if you want to make sure that your port matches the readiness port or just use that value, you can do that fairly easily. The other example is a little bit, you know, it's slightly different, but it's also very powerful where you can, you know, using something called James Path or JMS Path, which is a way of processing JSON data and it's supported by several command lines, including, you know, like the AWS CLI as well as kubectl and other support. James Path, there's a tool called JP which you can also use to test these. So what this is doing is it's extracting some data from the incoming request object and adding that to your policy definition. So the second box here is an example of how you can add a label into every, again, if you're matching namespaces or you're matching an object, you can now easily check and say, who created this, right? Because Kubernetes doesn't show that by default, this becomes a very simple way of showing who created that particular resource or namespace. So there's more complex, again, you know, expressions and things you can build and there's several samples. I'll quickly show the Kivarno website, our policy library. So like the first one is, again, taking data from the request object, which is sent by the API server to Kivarno and it's extracting the data and adding it to your policy definition itself. The next one is getting user information. So some of this comes from the API server, but other data is what Kivarno is fetching and automatically making available, right? So this is a built-in data type. It's built in and Kivarno augments what comes from the API request to make it easier to add, you know, checks to say if a user belongs to a certain, you know, role or to, you know, a certain, you know, cluster role or a namespace role, then you want to allow some logic. So you can match and exclude by this as well. And then the final example is another, you know, the turtle bullet here for built-in data is where you're checking against the images within pods, right? So if you want to check for a particular registry or a particular tag, you can now very easily and simplify this in your policy logic and just use this built-in data types. There's also a couple of ways to get external data and we'll talk about that next, right? So the one pattern Kivarno fully embraces. So just like in Kubernetes, Kubernetes apps typically follow the 12-factor app spec and configuration should be decoupled from your application itself. So either you're putting environment labels or you're using config maps, right? Config maps give you a very powerful and flexible way of managing this type of environment data. So, you know, here, what Kivarno does is it automatically scans and caches config map data and allows you to now use this within your policy definitions itself, right? So in this example, what we're seeing is we're reading from, you know, we're taking a config map, loading it into a context within a rule, and now we're using data from that config map and we can cross-reference this with other data, right? So you can form logic to say now if a pod has a particular image, take that image name, use that as a key in a config map, look up something else and then apply it to your policy. So fairly complex, but nice and easy declarative syntax to deal with that without, again, having to write, you know, code or do other complex things. Here's another example now which gets more into the power of Kivarno, right? So this is actually fetching data from the API server. So if you recall, when we talk about the exact model architecture, we, you know, we went through things like you have the policy enforcement point, the administration point, as well as you have a decision point where that policy is being decided, which is Kivarno, and then you have an information point, right? So the API server acts as a source of information. It becomes like a policy information point where your policies can fetch more data and make processing decisions on whether they should be applied. So in this example, you know, what we're doing is we're actually making an API call, you know, and so this policy is trying to check and make sure that you only configure one service per namespace of type load balancer. Now, why would you want to do this? Well, if you're running in a cloud environment, load balancer services tend to add costs, right? So one way of kind of, you know, one common, you know, enforcement is making sure that each workload only exposes one external load balancer and uses other constructs to do internal routing and traffic management itself. So to do that, now you can very easily define a policy which is saying, okay, do an API server call, check the namespace that the workload is going to get deployed on, and count how many load balancer services are there, and when you have that result, make sure that it's only set to one or if it exceeds one, you're going to deny that rule, right? And you're not going to allow that, you know, whoever is trying to deploy that workload to go ahead and create that new service type with the type load balancer. So again, you know, a fairly complex set of things that need to be done, but with Kivono, you can do this as a James Path expression and you can now, you know, filter down the results. So the first line here, which is doing the URL path, is actually doing an API server request. It's fetching the list of load balancers in a particular namespace. And then the second line is filtering that down and narrowing it using James Path. And by the way, there's, you know, interactive tutorials and things on the James Path website on how you can do this, so there's several best practices and patterns available. But what it's doing is it's, you know, filtering it down to match by a particular field and then kind of, you know, passing that into a function to count that. Kivono also has several, you know, James Path extension functions. So you can do things like regular expression matches. You can even do, you know, some computation, like you can do less than, greater than those type of comparisons. So just making it again very simple with a couple of lines of YAML declarations to be able to, you know, process API server data and things like that. It's extremely powerful. And the nice thing is you can test all of this using standard tools. So if you use Kupka, it'll get with the minus minus raw option. And if you use, you know, with JP, which is the command line tool for James Path, you can now test all of this and then make it part of your, even your CI CD pipeline, where you're automating the test for this, going back to that policy as code concept, making sure we're, you know, properly verifying before we deploy into, you know, these type of, into your production clusters itself. So one other pattern which is becoming, you know, in the community, fairly, you know, popular is how you can, you know, extend Kivirno itself, right? Because with any tool to be successful, it's always nice to make it extensible. And Kivirno, again, adopts a very, you know, Kubernetes, you know, native way of being extensible itself. So with Kubernetes, you can write, you know, custom, your own custom resource definitions, you can have custom controllers, and there are several projects which do this for everything like CertManager does this for certificate management, of course, like the storage controllers, networking controllers, other things do this as well. But it's very, you know, it's straightforward using tools like KubeBuilder to be able to create your own extensions as well if needed and when needed. So the way to kind of add anything to Kivirno, it's as simple as creating another Kubernetes controller or having a way to even push a config map from your CICD pipeline. So as long as you can do that, Kivirno can now, you know, leverage those constructs, a custom resource definition, because Kivirno can automatically, you know, query the schema through your API server, or it can look up a config map and it's able to also, you know, process the data in the config map itself. So this provides a nice and secure way to make sure that, you know, Kivirno can be extended and you don't have to, you know, kind of change the Kivirno source itself or deal with plugins or any other kind of complex way of dealing with other data providers or other policy extensions that you might want. All right, so let's quickly go through some other features. You know, we talked about how you can start with simple policies, how we can get to complex policies, but there's a lot more. If you're deploying in production, you know, you want to, of course, make sure that your policy engine, which is a critical component of your infrastructure, is properly deployed. You want, you know, reporting metrics, things like that to be built in and to be complete, right? So Kivirno, first off, reports in Kivirno are also full-fledged Kubernetes resources. So these are not, you know, again, like other tools sometimes pushed, you know, to logs to push to other data sources. In Kivirno, what we have done is we have made reports a first-class, you know, Kubernetes resource itself, which, again, you can use any Kubernetes command line tool or management tool to process and automatically, you know, utilize. The other cool thing about Kivirno reports are these are, you know, follow a CRD definition, which the policy working group in Kubernetes is standardizing and is promoting with a number of other projects itself. So Kivirno reports follow the same, this common CRD, which other tools like Falco, which is a runtime, you know, policy and kind of runtime security tool, as well as things like KubeBench. We're also working with other, you know, projects to start embracing this policy report. In fact, you know, even, you know, we've had discussions with the Gatekeeper project to see if, you know, that there could be an adapter or a way of taking reports from any other tool and, you know, leveraging this policy, you know, common format of reporting. So the nice thing with this is no matter which tool you're running, you can now standardize on the output definitions. So if you're interested in this, go to the policy working group, you know, website in Kubernetes. There is a CRD, there's a definition, there's a list of projects that, you know, either have existing support or a plan for support for this itself. There's also, you know, now that we have the standard definition in the community, one of our community members has built an awesome tool called Policy Reporter, which takes this definition from a graphical view of it and can also now extend, you know, take the, you know, as policy reports are generated, compare for differences and create notifications which can be sent to other upstream tools like whether it's a Slack or other, you know, notification and communication tools you might have, right? So this is another, this is now also part of the Kivorno project. So it started off, you know, outside the Kivorno project, but we have, you know, as a sub-project and Policy Reporter is also released and managed by the Kivorno community itself. And then, you know, there's built-in metrics which Kivorno itself exports, right? So if you're managing policies and if you're using policies for other security, how do you know your policies are working? How do you know, you know, how many times a rule has been executed and how many errors are there in your different clusters? So to do this, Kivorno has native integration or native support for a number of metrics which are very granular but can also be filtered and scoped with labels using Prometheus metric formats. So this makes it very simple and, you know, again easy to manage at scale. Here's an example of a dashboard with, you know, Prometheus metrics which is showing, and this Grafana dashboard is also available in the community to get started with. And of course you can extend and build your own as well if needed. All right, so and then the other thing to talk about is, you know, so as we talk about policy as code, you know, the runtime part, running Kivorno, observing Kivorno, managing Kivorno is important but you also want to integrate policies in your CICD pipeline and you want to, you know, try to, of course, enforce these best practices as early as possible as things are changing in your applications in your workloads. So to do that, most Kubernetes workloads also have now a set of yamls which, you know, kind of manage or specify how that workload should be described or should be deployed in a cluster, right? So when those yamls are updated, you can run CICD, you know, jobs using the Kivorno CLI which can automatically check and make sure those yamls are compliant to your policy. So this, the CLI has two purposes. One is for end-users, the workload owners to be able to verify and make sure their workloads are compliant and if they're not, you can just say if a PR or if there's a, you know, commit, you can flag that right away and make sure that if there's any problem with that workload that gets, you know, the author knows as part of the, you know, their CICD pipeline and they can fix that even before that commit is accepted, right? The other use of the CLI is for the policy authors itself. So for your ops team, you want to make sure you want to test policies and you want to manage policies just like you would with software best practices. So the CLI has a lot of support. There's a test command where you can write different test cases both for, you know, negative execution and successful or sunny day scenarios. So you can test a combination of these results. You can even test against a cluster and produce reports and compare them to what the expected results is. So this makes it very easy to again manage policies as software artifacts within your version control systems follow the best practices like you would for other software and apply that into your policies itself. So certainly the CLI becomes instrumental in that and it doesn't require a connection to a cluster. If you do want to test your policies against a cluster, you can pass that and it will actually verify, you know, a set of policies or changes in policies against a live cluster to show the results itself. So let's talk a little bit about the roadmap and what, you know, what's coming up, right, and in Kivarno. So Kivarno is at release 1.4 and the community is working on we're, you know, about to release 1.5. The goal is to have a release candidate before KubeCon. So in a few weeks, we will have RC for 1.5. And there's a couple of very interesting and powerful features coming in here. So right now, if you are configuring WebBooks, so remember we talked about the API server sending requests to the WebBooks like Kivarno and you could have mutating as well as validating WebBooks. But if, so today that WebBook configuration is manual in Kivarno and you have to write the filters, write what you want to pass to Kivarno. So with 1.5 that becomes completely automated and dynamic. And of course today you can say send everything to Kivarno and Kivarno enforces a very short deadline to be able to deal with that load and is optimized for that. But it's better, you know, with this change, Kivarno will only configure the WebBook filters for the specific requests that are required and this will, you know, kind of help its scalability as well with processing. There's also a new construct being introduced for more powerful processing logic in Kivarno. So a lot of Kubernetes resources have sub-resources or sub-elements in them, like a pod may have volumes, right, or a pod may have container definitions and a lot of times you want to kind of loop across these and apply some logic within these rules. So the for each construct just simplifies that. Today it's possible but it's quite verbose. So this will just simplify it and make it easy to write these type of, you know, more powerful constructs itself. There's also more features coming on supply chain security where Kivarno will be able to, you know, have support for attestations, other things which are being developed in the cosine and six store communities. So we're collaborating with these projects to make sure that Kivarno policies can apply some of this added mission control itself. There's also a time-based, you know, request in the community, which was very interesting, right? So this is talking more about time-based policies. So to be able to apply policies, you know, only in a certain threshold of time. And you may want to do this like one use case was, well, what if you have certain users on pager duty rotation or, you know, they are kind of responsible. So only some users should be able to update clusters or do certain operations at some given time. These policies can do those checks and can alert and audit if, you know, some other users are taking actions at that time. And there's also other requests for more powerful, you know, processing logic. And, you know, one consideration is also to support things using languages like JavaScript, which allow, you know, writing some custom logic if and when needed, right? So just to quickly summarize, you know, and we'll, you know, I think we have a little bit of time for demos, so I do want to show some, you know, a quick demo of what Kivono looks like in action. So actually let's switch to that and then I'll come back and we'll summarize on this. So I'm going to, you know, go from to my command Lenshell. And here if I look at, you know, what's running, I have a local cluster and if I just check the namespaces on it, you can see I have Kivono installed a few other namespaces and things running in here, right? So now if I check and see what's in the Kivono, you know, so let's do minus and Kivono. Spell that right. So in this case, I've just done the default installation of Kivono and you know, that brings up a single deployment with a single pod. You can, of course, scale this up as you need. And if I do, you know, let's say if you just check the logs of this and, you know, I don't really need to follow the logs. I'll just do, we'll check for the deployment. What we'll see is, you know, Kivono is up and running and it's showing us that, you know, everything is healthy. There's some TLS handshakes, but this is because I'm running in Minikube and there's, you know, my firewall port here is not open on this. So Kivono is already running. The other thing I want to check and see is which policies I have, right? So I'll just do a get C-Pol, which is cluster policy. It's a short name. And if I look at it, I have two policies. One is running in audit mode and the other is running in enforce. So the first policy is saying that if I have a pod, I want to require probes for that pod. And the other policy is, you know, showing, saying that if I, you know, have, you know, is verifying images itself. I can also check over here if I check for policy reports. Again through, you know, policy report, the short form is PolR or P-O-L-R. So I can check and see that I have one policy report and it's showing me that everything's passing right now. There's no violations in my cluster. So pretty easy, pretty straightforward to do. So let's actually now I'll demonstrate the supply chain security example, right? So what I'm going to do is the check images policy we looked at before is this policy which is verifying that any image deployed in your cluster has to be signed with this particular signature. And this, you know, I have a test image in the Kivarno repo which we used for automation test as well and we're just going to test against that, right? So the first thing I'm going to do is I'm going to apply, this policy is already applied so I don't need to do that actually and I'm going to run a signed image which I know has been signed with this signature. So when I do that, Kivarno will, you know, of course the pod gets created so if I do let's check for the deployment. So we have now signed the deployment is running and as you can see it has one pod running and everything's ready, right? So now how do we know anything happened here? So let's check, let's speak at the YAML and if you look at this and if I want to grep for image what I'm going to see is there's, let me move this to the top of the screen. What I'll see is that signature actually got changed to insert a hash. So when I deployed the pod, if I look at the pod declaration or the deployment itself that hash did not, you know, the digest did not exist but now this got inserted by Kivarno because it was verifying that it actually pulled that information using cosine against your image registry, checked the signature, mutated the pod in the deployment itself. So any instance of that pod that gets created now has the proper hash or the digest within your cluster. So the next thing we'll do is we'll try and run a pod which is not signed, right? So I'm going to pull this deployment will create the unsigned with this image which we all have in the Kivarno repo which is unsigned. So at this point as you would expect the admission of that book itself says it checked the signature and is saying this image is not really signed so, you know, it's going to deny and it's going to block that from executing. Another test would be if I have let's say I have another deployment which is signed by some other signature. Now in your rule you can specify as many signatures as you want. So if you want to make sure that each pod is signed by, you know, there's an attestation let's say for your commit and other things you can combine the signatures but in this case it's some foreign signature so Kivarno again, you know, uses cosine does that check and will immediately block that pod and say this is not allowed in this particular cluster. So just a simple demo but a quick example of showing, you know, how you can now use these policies to start enforcing things. There's several other, you know, you know, policy examples I'll quickly show the Kivarno website itself. So if you go to the, you know, Kivarno website at Kivarno.io look at policies. There's several policies which you can, you know, give you a really good starting point. The thing that if you're not running PSPs today or not using some other tool for pod security, I definitely recommend checking this out. In fact, you know, I can show a quick demo of this as well. So here what I'm going to do is I'm going to put this in my cluster. We'll just use this one command line to apply all of the pod security policies available, right? And there's about 15 of them defined in Kubernetes. This is, there's a spec called the pod security standards which defines three levels of pod security. And what this is going to do is it's going to put the highest level of pod security in my cluster. So it's a number of policies and we're applying a customization to them to switch these to audit mode. So if I do now a kubectl getSeapol, which is cluster policy again, I see I have a bunch more, a lot more policies, right? Now let's try and, you know, take an insecure pod. And I like this one. There's a website, you know, maintained by Bishop Fox called Bad Pods, which is interesting for testing. So this is, the reason why is this bad, right? Because it allows privilege mode, it allows, you know, running it in the host namespace, using, you know, host bid, host path, the host network itself, and also host IPC constructs, right? So definitely not a good thing to run in your cluster, because of course if an attacker gets access to this pod, from there they can also, you know, kind of leverage other things. So I'm going to go get YAML for this. And so let's go with this first one and we'll just go to the raw definition and we'll grab the command line. Let's see if we're able to run this in our cluster. So this is pulling down that, you know, demon set YAML and immediately, of course you see a bunch of errors which are saying that, hey, you can't run this workload because it's not configured for security and it doesn't comply with the policies we just installed, right? So quick examples, there's lots of other more powerful demos in the community on the Kverno website itself. So certainly take a look. But just to summarize and wrap things up, yes, so Kverno is designed to be a fully Kubernetes native policy engine. It runs inside Kubernetes clusters as an admission controller. Also understands Kubernetes constructs, which makes it very easy and simplifies managing, defining and enforcing complex rules within your production clusters. So what Kverno helps with is securing and automating your configurations at scale and doing this, you know, again, so across your DevSecOps roles so you have proper separation of concerns as well as you're promoting best practices. And Kverno is like we saw is extremely simple to get started with and certainly with the, you know, like use cases like pod security, best practices for your workload, it gives you a lot of benefits right away. So certainly check out the community site so you can just go to Kverno I.O. for all the information. We are on the Kubernetes Slack, so if you go to Slack.ka. So Kubernetes.io there's a Kverno channel and we have, you know, monthly community meetings for end users. We also have weekly contributor meetings and growing set of contributors who are also helping extend and manage Kverno. So that's what I had to cover. So thank you very much and pleasure presenting Kverno to everyone.