Red Hat OpenShift OpenShift Commons Briefings, 29 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kyverno: Kubernetes Native Policy Management Ritesh Patel & Jim Bugwadia (Nirmata) OpenShiftCommons

Description

Kyverno: Kubernetes Native Policy Management Ritesh Patel & Jim Bugwadia (Nirmata)
OpenShift Commons Briefing
03-29-2021

Kyverno is a policy engine designed for Kubernetes. With Kyverno, policies are managed as Kubernetes resources and no new language is required to write policies. This allows using familiar tools such as kubectl, git, and kustomize to manage policies. Kyverno policies can validate, mutate, and generate Kubernetes resources. The Kyverno CLI can be used to test policies and validate resources as part of a CI/CD pipeline.

Kyverno is a CNCF Sandbox Project, and in this OpenShift Commons Briefing, Nirmata’s Ritesh Patel and Jim Bugwadia will give introduction to the project, a demostration, walk us thru the road map and answer your questions.

A

All right, everybody welcome again to another openshift commons briefing. Today, it's a wonderful monday in the world and we are doing amas with upstream projects and today we're going to talk with two folks who are the people behind caverno, a new cncf sandbox project.

A

I believe um ritesh patel and jim baguadia, and I'm going to let them introduce themselves we're going to have a nice presentation about what caverno is doing and why and when and where it fits into the whole cncf landscape and then we'll have live q a at the end, so ritesh and jim take it away.

B

Hey folks, uh I'm british patel bb products and co-founder at mirmata.

C

Hi everyone- this is jim baguaria, co-founder and ceo at nermata,.

B

Right so, let's uh dive into.

C

It so today, we'll.

B

Talk about uh you know: kevorno kiberno is an open source, kubernetes native policy management uh solution. uh That's uh now a cncf sandbox project. So here's the agenda. I will you know dive deeper into. Why kevarno? What does it solve? um Why? Why did we feel there was a need for something like kiwano and then jump into uh the technical details of how it works.

B

Now we do have some use cases that we can go over to uh give you folks of you know an idea of the kind of problems you can solve using kubernetes.

B

I will discuss some of the other uh tooling around kubernetes, which, uh more specifically, that the nirmata offers to help help uh ease the the you know: uh management of kiberno policies and and reporting, and then jump into a demo, followed by a quick uh road map and q a so let's, let's jump right into it, uh kiberno! Actually, uh you know you may kind of wonder what what does kevin do mean and kevin actually means governed uh it. It's a it's a play on as it's in greek.

B

Basically, it's governed and you know obviously kubernetes uh the origin of kubernetes. The word is, is uh from greek, so we thought it would be uh appropriate to kind of use uh kiwerno, as uh as as as the name of this project, because kiberno is essentially a policy engine for kubernetes and uh policy engine uh is used typically to to to govern or for compliance of of various aspects of um of kubernetes.

B

So that's why the name kiwano uh kiwano, uh the is a kubernetes native policy engine which means that it understands kubernetes resources, uh kubernetes patterns, so it actually is aware of of kubernetes communities constructs, and it's been it's it's designed in a way that it's familiar to kubernetes users, and essentially there is. uh There is no learning curve.

B

So let's take a step back and understand. Why uh do we need policies and kubernetes? What are policies? And um you know how do they help? So, if you're familiar with kubernetes uh kubernetes, uh you know you can configure uh lots of uh different resources, whether it's you know your infrastructure uh for kubernetes, whether your app applications or workloads running in kubernetes and all of the configuration is essentially done using um you know yammer right and it gets fairly complex. Some some configuration files could could be.

B

You know a few hundred lines and and the the challenge there is now. How do you ensure that the configuration can be managed and is secure?

B

There are also you know, external tools that uh that, for example, helm and customize that tweak existing configuration to adapt it to environments.

B

So that's what that's, how your configuration could change the the the end configuration that ends up in the cluster may be different from from the source, depending on. Where is where uh your your resources are deployed, so you know in kubernetes uh there is, there are ways to uh to configure admission controllers and that's where, as a best practice, a lot of the validation for configuration as well as any modification or mutation or configuration can happen, and that's that's.

B

Why that's the kind of the best place where policies, if any, can be or should be applied? So what what kiwano? What policies do is? Essentially let you govern or or ensure that the configuration that's being you know applied to kubernetes is secure. It follows your best practices. You know follows the standards and, uh and kiberno is an engine which does that without the user or the developer or the cluster operator having to build something from scratch or build something custom for their environments.

B

So that kind of brings us to why furno and- and you know touched on this briefly in an earlier.

C

B

But with kiwano our goal when we started out was to enable policies for kubernetes and make it really really simple, make it really easy for uh users to understand and write these policies, so kubernetes policies are uh declarative and very easy uh to manage the and and when these policies are applied, they generate uh uh policy results. uh Basically, these are you know, violations or or any kind of any.

B

um You know any policies that are violated kind of are reported in in the results, uh so that it's also is kubernetes native um these policies are can be of different types. You know you could have a validating policy which can either be an audit mode or an enforced mode or or they could actually mutate. An existing configuration by uh you know changing parts of parts of the configuration or they could.

B

The policy could generate new configuration if it's, if in cases where this configuration is required or it's it's missing, and that gives you a lot of flexibility to kind of ensure that the configuration of your kubernetes applications and resources are configured correctly.

B

um The being kubernetes native uh kiberno supports all of the kubernetes resource types and can also support um uh custom resources right so, which is a huge uh benefit so that you know now. You can use given across the board without having to worry about which resources are supported and which are not, and you know, being again being kubernetes native giver, no leverages and understands. You know some of the common patterns used in kubernetes, like label, selectors tables and selectors annotations, owner references and and and things like that right.

B

So that really makes it very uh easy for somebody to to you know, start with kiwano and start using it with kubernetes.

B

Now, just a little bit of uh background on the project itself. So cubano uh today is an open, is open source and a cncf sandbox project. It got the it was added to sandbox projects in november last year and since then, we've been tracking the downloads, and it's almost uh approaching 2 million downloads in you know about three and a half months right, which is which is huge uh it. It went to one million downloads uh about three or four weeks ago, and now we are almost there at two. You know two million downloads.

B

So seeing a lot of uh you know uh interest in the community.

B

uh You know a lot of folks are looking at it and and like the simplicity, ease of use of kiwano um and and then ha there are other projects in in the cncf and in the community like open policy agent uh which which uh which do uh policy management, but uh uh cuberno kind of because of its simplicity, has been gaining a lot of a lot of interest and and a lot of users so uh definitely do check it out.

B

If um you know you're interested so question, when we talk about kubernetes question that comes up, is you know, I was given a different from open policy agent, and here are some points of differentiation.

B

um You know uh open policy agent was was actually predated. Kubernetes was built as a general purpose policy engine and then adopted or adapted to kubernetes, um uh whereas kubernete itself is designed for kubernetes. It's kubernetes native.

B

The policies are kubernetes native resources in kiwano, whereas an open policy agent, uh the the actual policies, are defined in a language called rego, which could, which is something that a user would have to learn to write policies.

B

There is a a project called gatekeeper which, which works or integrates with open policy agent that simplifies or that tries to adapt, kubernetes resources and and um uh to define policies, but ultimately, uh the underlying enforcement and all the all of the the policy processing everything happens based on um in based on policies written in rego, also, a few other things about uh kiberno, which are not necessarily available or possible, with opa oppa gatekeeper.

B

So kimono is, is you know, secure by default? You don't need to call out any external systems for any processing, and you know because it's an admission control path. This is very important and also a few other scenarios that you wanna enables are around. uh You know just kind of the if this is in that paradigm, where, if, uh if a particular configuration you know, if you check for a particular configuration and if it exists, you can actually write policies to do certain things.

B

These are very easy to do in kubernetes and being kubernetes native and uh given the policies are also kubernetes native, it lends itself very well to tools like you know, customized sound, and can you you can use githubs to actually apply policies across your clusters, so really just in a nutshell. There are several benefits um that that you get with kiwano in terms of ease of use, as well as the other capabilities.

B

Let's dig a little bit deeper in in, in terms of you know, uh at a high level, from uh from the policy perspective for kubernetes and we'll go a little bit more details into how cuban policies are defined, but here this is just to show it kind of the difference between and oppa, on the left hand side. You see the commander policy, which is um you know if you are familiar with kubernetes and abused um kubernetes resources like deployment spots. This will be very familiar to you.

B

uh It's very uh you know straightforward in terms of writing these policies. There are certain keywords like match and validate and we'll talk about those a little bit later, but um overall in this policy uh just um validates and checks. If you know the file system is read only on the right hand, side, you see the same policy written in in indigo, and this is this would be something that you would um use in opa. So this will just quickly show slight difference between kiwano and oppa.

B

So next we'll talk about how kiwano works uh I mentioned earlier. Kimono is a policy engine that runs inside the cluster and it registers you know as an admission controller and then it every request that comes in through the api server uh is, is processed through kiberno, and you know, policies uh that are configured in in kubernetes are applied to to these requests.

B

So it kiwano gets an admission review request. It uh applies these policies, the policies, depending on on the configuration, may generate certain events or a policy policy violation, and then the response is sent back.

B

If the policy is configured as as audit only then it's really uh the the the it's just in a kind of like a report, only mode and um there's no, the request itself is not blocked, but if the policy is configured as as uh you know, to configure to uh validate and block, then the the request can also be blocked uh if the policy fails. So this is really at a high level uh how kubernete works in kubernetes.

B

Here is a quick view of the policy structure, so when you're defining a policy in kiberno, a policy contains one or more rules and each rule contains a match or exclude criteria which could be map to kubernetes resource kinds names. It could be. You could use label selectors, namespace selectors, as well as user roles, groups and so on, and then you have the the various um actions that cubano can take.

B

You know that's either validate mutate or generate so so these are the high level blocks and we'll talk about each of these um blocks in the next few slides.

B

So, just to map the the the structure we saw earlier uh here we have um the same kind of uh the kibona policy, showing the same structure where you have uh in on the top line number eight. We have the the match block where in this case it's matching uh all resources of kind pod and then on line number 12 we have validate block which actually does the you know, does the validation for for every port, and in this case it checks if um the security context run as non-root, etc group.

B

So so this kind of gives a quick idea of the the policy structure.

B

So validate policy is um essentially it kind of matches, uh the fields that are defined in the validate block and and determines. If, if your configuration, uh you know, matches the matches of fields and- and you know it is it's validated for um it- validates the configuration by matching all of the fields.

B

So in this case you could have patterns, you can match, uh you know, for existence of fields you can match, for uh you know with operators you can have you can check if values is, you know, are greater than equal to or not equal to. So a lot of the uh there's a lot of flexibility in terms of uh doing various types of uh matching uh in in in these policies, in the backwards for validate.

B

Next on the mutate policy, so here you can, when, when you want to mutate an existing conflict, you can specify a kind of a patch, a json patch or strategic, merge patch to update the incoming resource. So, for example, here, if you want to let's say, add a port or, or you know, insert like a secret name, you can do that by specifying the patch in the policy, and you can even do that conditionally. So you can.

B

Even you can only add a configuration if it's not there or if, if, for example, you can even have, if then condition where for certain port names you can use for certain. Only if port names start with certain string, you can, you know, add the add the value and so on. So this gives you again a lot of flexibility to to manipulate incoming incoming configuration and uh it's actually very important. There are use cases where you know.

B

If you want to add certain labels on on every resource or or on specific resources, you can now ensure that that's done uh by creating a mutate policy a lot of times. These labels could be used by other tools for security, for networking, for monitoring and so on.

B

So so you know, given uh through mutate policies, uh allows you to address some of those uh use cases, and then the the final type of policy is a generate policy where you can actually generate certain resources, so so, on the the example here, on the right hand, side kind of shows how you can generate a network policy uh to deny all traffic.

B

This could be your default network policy for your namespace, and uh it can, you know it would be created. Maybe anytime, a new namespace is created, so there is a usually a trigger which can trigger the generate of um of these these resources.

B

In this case, uh we are generating a network policy, and it could also you could use to clone existing resources, and- and this essentially allows gives you flexibility to ensure that uh you know certain required resources like network policies, uh quotas limits, things of that sort are always available in your in your cluster or for your applications.

B

When these policies are uh configured once these policies are configured and and and as they are processed uh based on based on uh incoming requests, there are violations that that can be generated. So here is an example in kubernetes uh to see the policy result. So on the top, you see an example of uh uh showing the of the policy results for a particular namespace in this case default namespace, which shows that you know nine uh policies uh were passed and one failed and you can get get more granular details.

B

um You know like, um like the exam like the second screenshot here, to to see which policies failed and what exactly uh why exactly the policy failed right, so you can get more details in terms of the violation so.

C

B

Violation can be fixed, so that's kind of you have that information again, it's all inside your cluster. You don't need an external tool to to retrieve that information.

B

So uh this was a quick overview of some of the features, but there's lots of advanced features uh that are being built, and you know this is an ongoing kind of, um as community comes up in more use cases we're building more and more features. So we talked a little bit about you know. Some of the anchors operators, like you know, compare comparators and, and if then else and so on, um you can also have variables.

B

uh You can actually point to certain certain parts of your config using jmes path, james path- and uh you can also look up data external data- um you know from from config map or to api calls, and this let's uh this allows you to kind of um check or trigger you know, violations by checking data that may not be part of the incoming request and or a part of part of the the resource configuration you can also set up deny rules. uh One thing: that's interesting is auto generation of partner controller rules.

B

So if you have policies for parts they automatically get applied to port controllers, like deployments, uh stateful sets jobs and so on, and then finally, uh kubernete can also be run in offline mode. So you don't there's a command line for qrno which can be used offline so that you can actually check check for uh violations in your configuration if it's in gate- or you know, before your config check, for your violation before your configuration is applied uh to um to your cluster. So that's definitely useful.

B

uh You know you want to don't want to wait. Till uh till the configuration is in your cluster to check you can check up front address those issues before applying your resource changes to your cluster.

B

A

You know we talked about.

B

A few use cases, but there's more uh use cases emerging as as uh as uh kuberno gets uh more widely used. We talked briefly about security, validation and enforcement.

B

There's also uh kubernetes enables you to do find green, our back uh so based on um you know, for example, uh when name spaces are created, you can also create some of the roles, role, bindings, etc, depending on the name, space name or labels, or any other criteria.

B

Kibano is uh enables multi-tenancy in in kubernetes again through some of the automation, by generating um our back rules by generating network policies can generate uh quotas, and you know we're also working with uh various states to kind of enable this enable more secure multi-tenancy across within within kubernetes.

B

You know for for your applications. uh Auto labeling is a use case. We talked about earlier uh also, first, uh a lot we are seeing patterns. Like you know, side cars uh uh being used in for various uh um various tools, like you know, for for, for example, for service management. Is your side car, it's very common to use side cars. There are other scenarios like if you want to mount certificates or or if you want to uh you know fetch.

B

You know continuously fetch data from some of the uh some uh end point for things like that. You know side cars are being used like, for example, even for uh you know, wall certificates and so on, so kiwano also can can, because it can mutate existing interpretation. You can create sidecars using kibana, so you don't have to write a new operator to do that and then, finally, you can have very uh conditional rules like if this and that for kubernetes and that opens up a whole set of use cases.

B

uh You know for your uh in your in your kubernetes deployment, so it's very flexible and you know we're happy to kind of if you have other use cases that we have not covered or we've not seen, be great to hear uh about those and see how we can help with using q1.

B

C

B

Where you know we really see a lot of interest today is around. You know: pod security.

B

um In the past, uh port security policies have been defined using psps, but uh psps have been marked for deprecation uh by the by the community, uh and there are other options and alternatives being discussed, and we are part of those discussions.

B

But uh today, if you want to, uh if you are interested in in the port security policies, kiberno provides a very easy way of of achieving that. We already have a set of policies. uh You know in our on the kubernetes website of it and which kind of address all of the requirements of you know for for port security, and they are based on on levels.

B

You know like we like the like, psps and and some of the discussions that are happening in the community, so it would be um all uh you could should, uh if you're interested in uh alternatives to psps. uh For while uh you know communities working on you know the next uh iteration of psp, it would be great to check out kiwano, and let us know if that addresses uh the security needs.

B

A lot of a lot of folks in the community that we know are already using given of our port security, so something you know you can try out, and um you know let us know if there are gaps that we can.

B

Address so uh before we jump into the demo. The one thing I want to quickly touch on is uh you know, as as uh kiberno gets uh used in kubernetes and it's as it's more white widespread.

B

uh You know we're seeing uh some requirements around managing policies at scale across clusters uh across multiple clusters, ensuring you know, consistent deployments uh and uh and so on, and so we've created. uh You know a cloud-based solution at nermata to help manage policies at scale. So through nermata you can actually deploy policies uh across clusters. uh You know using githubs, but there's a concept of policy groups.

B

You can define different policy groups like say for pod security or for multi-tenancy, and then these groups, these policy groups, can be applied either automatically to new clusters or they can apply, be applied to specific clusters.

B

um So you can manage it very easily instead of having to deal with each cluster individually right and then the ongoing challenge of keeping your policies up to date and automating. That deployment can also happen.

B

um You know very easily with uh with our integration, with kimono, with the integration of pneumatic one and then, if you want to generate a lot of violations right so depending on the size of your clusters and the number of pods and the number of applications running, you could have tons of you know: policy violations, failures and so on and um policy reports are available in the cluster.

B

But through our integration with kiwano through, you can actually get a very granular report of of the violations and not just get the report, but then also understand what the uh what the problem is and then you know either get get help on remediating that problem or filing you know, tickets to kind of get that problem from remediated.

B

uh You know from the application owner and so on. So uh through the integration we complete the the full life cycle and of managing kevin policies and and getting visibility into kubernetes.

B

You know at scale right if you have multiple clusters that you're managing this becomes very, very important.

B

Next, we'll jump into the demo, so I'll stop, sharing and let jim take over from here.

C

There we go yeah, so what I'm going to do is I'm going to just demonstrate. You know how you would, as a new user, get started with cabrano what you can do with it. We'll look at a few different examples.

C

uh We'll look at you know like ritesh mentioned pod security policies get a lot of attention. So we'll start with those see what kiberno can do in that area and then also look at some more advanced policies. So I'll just go. You know just again going to the caverno site if I go to documentation and I'll we'll click on installation, so we see there's a bunch of different ways to install there's a helm chart, but for this what I want to do is just install using a command line.

C

So we can kind of look to take a look behind the scenes and see what's going on right, so I'm just going to copy this command, which is a single line to pull down all the ammos from the kiberno git repo and install into my local cluster right. So if I do cuddle get namespace you'll see, I I'm just using docker for windows here and on this I'm gonna run.

C

You know this command line that we copied and have it installed, cabrano right, so we see there's a bunch of crds. That's all of these that came in about like six or seven different crds, including policy reports. One interesting thing I want to mention about policy reports is: these are not unique to caverno. In fact, the policy reports are being developed.

C

uh You know in in collaboration with the workgroup policy, the policy working group in the kubernetes community and the intent is to make these same crs available to any other tool that wants to report policy results.

C

You know in in the kubernetes cluster right, so this provides a standard way of reporting policy violations, independent of the engine or the tool. That's producing it and there's some work being done to take. You know things like cookbench and also adapt it to these policy reports. Falco is being discussed as another candidate, etc.

C

So so, once these cr these are installed. We also see that kiberno created a service account. There's also a few other things done and what's also interesting is there's some web hooks created right. So now, if we look at our namespaces again, we should see a cabernet namespace.

C

If I do you know minus and giveno and if we let's say do pods, we should see that we have a single pod running, which is what we expect at this point right. So now, let's go ahead and you know I don't have any policies and if I do uh couple get cpal, which is short for cluster policy, it will say I don't have any resources, because the crd is installed.

C

I can actually now use something like poop cuddle, explain and I can say policy both has a cluster policy which is cpal and just policy which is a namespace policy and if I say policy spec, it will tell me you know, because it's integrated again with kubernetes. I can see right here what I can put into a policy.

C

So I see I have a background option, which is a boolean. I have a set of rules in the policy like rotation is explaining, and then I have a validation failure.

C

Action which can be set to either enforce or audit right, and if we go further so on it's very straightforward and of course, if you have your you know, visual studio code or other things integrated with kubernetes, you get all this help and you know schema, etc now, also in your um ide right, so makes it easy to write policies check the syntax things like that. But here I can see that this is the description of rules, but so far I don't have any policies I just have kiberno installed.

C

So let's go ahead and you know get some policies right. So I'm going to go back to the cavernous site and we'll click on policies, and I see I have pod security, best practices and other. So let's go to pod security and, like ritesh mentioned um here, the way these policies are organized is based on the pod security standards.

C

So if you're not familiar with those, these are, these are great to you, know, review and look at because what the kubernetes spot security standards help you do. Is they organize?

C

You know the pod security controls into three categories, so there's privilege pods, which is basically unrestricted, there's baseline, which is you know, used, is typically used as a default, so this is minimally restrictive and then there's restricted, which is the highest level of security itself right and then it lists every control uh within the pod, security, security context, structures and the allowed settings etc.

C

For those now the you know, the um the cap, which is being developed, which is most likely going to be called pod isolation policies, is also going to be based on pod security levels. So again it's important in port security standards.

C

So it's important to kind of keep these in mind and then you'll be able to apply these these one of these levels to spaces um in this upcoming you know kept, uh which will be pod isolation policies, so anyways going back to the kiberna policies. As you see, they are organized to default, uh so this is actually baseline. um It got renamed from default. So this is the baseline setup policies and this is restricted.

C

If I go into default, we'll see you know each policy, that's you know part of this. If I click on any one of this, like, for example, let's say the required default proc mount, so it is checking both for init containers and containers that if a proc mount is specified, it has to be default. It cannot be changed from that setting right, but there's other, of course, several other policies.

C

If we go back to you, know the restricted and look at some of the more stronger or the tighter control policies. You'll see things like require. You know that run as non-root, which is pretty important for non-privileged pods, to make sure both in it containers as well as containers are always run as a non-root user right. So let's go back. You know to this main pod security page and what we have over here. It's showing me a one line command, so users customize.

C

It pulls down policies from this git repo and then it's just using coop cuddle to apply them right. I'm going to take that and let's see what happens if we apply to our cluster, um so I'm gonna, you know it's a this, takes a few seconds to pull down all of the yammels and once that's down what we should see is. It will apply um into our cluster itself right.

C

So we see about like about 10 or so policies got applied, and if we go back and look at the cluster policies, we should see that these are now enforced. Now, what's interesting is if I go. Let's actually, you know look at this. If I go to one of these policies, if you notice, when I was browsing through the policies, most of them are written at the pod level right, but as ruthesh mentioned, one of the things kiverno does by default is because it understands the relationship between part and part controllers.

C

It will, let's take a look at that. You know root policy. Kiverno will automatically generate policies for different part controllers and of course you can control this setting. So if I say couple uh get you know, let's say cpal, I'm gonna do this and do minus yaml and then I'm gonna just to kind of get better, we'll use good, puddle neat, which is a really handy plug-in.

C

If you want to remove things like you know, which you don't want to see like all of the metadata and the or the owner, references things like that from the yaml, so you're, if you notice what happened is when I applied this policy, it was just written. The rule was written to match a part, but in addition to a pod, what happened is kiverno automatically generated policies, for you know most of the standard part controllers, and again this can be you know tuned.

C

You can specify different annotations to control, uh which you want to if you want to restrict, for example, only to deployments and not to demon, sets or something like that right. But here what I wanted to make sure is now we do have all of these uh generated. It's this one's for a cron job. uh This other one is for all of these. You know the more standard part controllers, as we see so pretty neat that I have now all of this installed. So let me try and run a simple workload.

C

um You know, I think I have an nginx pod, so I'm just going to say, create minus f, and let me check if this is in my template, yeah. So, okay, so immediately, kiverno is saying and because these policies were set to enforce it's saying that running as root is not allowed.

C

It's telling me what exactly got violated and it's saying that run as root must be true, must be set to true um run, as non-root must be set to true both for init containers as well as containers right, so that was since that was violated in my ammo. It's going to basically block this particular configuration itself.

C

So now, let's try something a little bit more intrusive right, so I'm going to actually use this site, which is pretty handy. If you haven't seen it, it's.

C

The site is bishop fox and it's called bad pods and, as the name suggests, these are pods which are misbehaving right, so pods which are misconfigured um to allow you know all sorts of. um I guess, oh to basically be open where, if you want to you know, um you know, allow post bid or access to host network or other name spaces.

C

uh All of that is fairly open right. So here I'm gonna go into uh let's check and see so this the you know which one we want to do: let's go into everything allowed, which is probably the worst. You can do right and we'll take a quick look at the yaml. We'll actually go to the deployment just to see how that works, and you know we'll look at it. So this is basically alarming. You know different, it's saying, privilege, true, it's mounting host, which is also a bad thing to do.

C

um It's all and then allowing all of our you know whole name spaces to true right. So let's grab that and what we want to do is we'll go to the raw ammo and we'll run that in our cluster right. So I'm going to now do coop cuddle, create minus f and we'll give it that whole ammo and see what happens so now we see a lot more warnings or a lot more. You know errors coming back from our admission controller, which is what we expect.

C

So it's saying that hey you don't you know, don't allow host namespaces, don't use hostpath, uh it's a dome privilege. So all of this got blocked, which is a and, of course, the other error we saw before, which is run as an android.

C

So this is how you know straightforward and simple: it can be to you know, to set these policies. These policies are very flexible. You can tune them based on you know, like rotation is explaining a lot of different selectors, um and you know I have some examples in here. So this is actually a different policy. It mutates uh or this is generating a network policy. But if you look at another policy like which also can mutate things, um so, let's yeah this is a example of a mutate policy.

C

um It matches also pods, but you can write your your selectors based on several you know, constructs including namespace labels, etc, right so very flexible, very simple. You know to apply some of these um one. The other thing I want to quickly show is how you know you know. Ritesh also mentioned some features like being able to select and get external data right. So very often you want to write a policy, but you want to then you know leverage data from things like config maps, which are very natural in kubernetes.

C

In fact, you know in in the community. One of the policies that I was just working with somebody to develop is to make sure that workloads um workload identities are protected based on the image name. So you know what the author did, which is pretty nice, is use the config map to make sure that a certain service account um can only be used for certain images right and they're managing this uh the data through a config map, but then it's a very generic policy to do that.

C

Another common example is, to you know, make sure your ingresses are unique uh within a particular. um You know. Cluster right, your host names for your ingress, I should say, are unique. So kiverno has this ability to use jamespath and also to do api look calls. So this is a combination of using those two features so just going through the structure of the policy, this policy matches ingresses and then there's a context which, where you can populate different data and different variables.

C

So your what it's doing is it's saying um it's doing a call to you know to the api server, which is this api call construct it's getting all the ingresses from the api server and then it's applying this james pat on it to extract out all of the hosts and then it's checking. If that host is you know, the host from the request object is already is included in that list of existing hosts. It's going to deny the operation right so fairly, complex logic, but pretty straightforward.

C

You know once you kind of get the hang of how this is structured and the interesting thing is, you know if you use group cuddle- um and you know just through the command line. All of this can be tested very easily. So I can do coop cuddle. um I think it's get minus this raw yeah. So if you do coop cuddle get minus finished raw.

C

So here I don't have any ingresses in this cluster, but um you can kind of see what that looks like, and even if you want to test the the james pat expression, you can use jp, which is the command line for that, and if I go back to my policy, let's grab what this looks like and, of course, if I had some ingresses this would maybe make more sense. But if I apply this right now, it will come back with an empty string right because there's no there's nothing.

C

So it just came back with an empty list over here. As you see, if I had any ingresses with hosts, it would show me a list, a string list of those ingressos and then in my policy. What I'm doing is I'm checking to make sure that the host which is coming from the request object, is not, you know, already used within the cluster.

C

So you know this is a simple example which shows again how you can combine some of these. The other thing you know, which is very interesting, is there's. You know, policies I think ritesh mentioned also for multi-tenancy.

C

I can show a few examples of you know. Those um what's we're seeing is. First of all, you know, adding labels to namespaces is is a very common use case and there is a you know, there's a session um that you know I'm going to be doing along with adrian ludman, who leads a hierarchical, namespace controller, a project that's also being developed uh in in the community.

C

uh We're going to be doing this at the cloud security day for kubecon eu, where we're going to talk about how kiverno and agency can work together and manage both namespaces and then hnc allows you know sub name spaces within a namespace, so how you can kind of allow that with those controls, so you're anyways in this policy, it's it's pretty straightforward.

C

It's saying that if there's a namespace created, except by cluster admins or by the hnc manager, go ahead and inject like the user info uh and then you can also do more complex things like you could say. Okay, maybe I want three types of namespaces. I want a small, medium large and, based on that now I'm going to configure you know different quotas and different things for my tenants right for my users, so all of that can be fairly easily done.

C

You can also generate very fine-grained roles and permissions, so only the the person who requested that namespace the owner will get permissions to then delete that namespace uh things like that can be, then you know um generated on the fly, so these are cavernous policies to do those kind of things. So we'll share this repo. Once once you know we we have this finalized for the session, but this is just a quick example of how now you can use the power of you know, leveraging labels and then based on automatically generating different.

C

You know configurations for those name spaces and of course you can also add, like validation, logic, to make sure that only the the right settings like in this example it was requiring that each namespace only have a certain you know can only be used with a certain uh suffix right, so dash sm or medium or large, and if it doesn't have those it would be rejected itself.

C

So these kind of things you know you can combine, you know validate mutate and generate to get exactly the right behaviors you want for your cluster and once these policies are set, they can they're very much data driven. So um you know the configurations itself can be easily automated in there okay. So one last thing I wanted to show you know before we uh switch is you know in caverno?

C

I think like radish also mentioned, and as we were looking at there's this ability to um you can create it, creates policy reports and something our one of our community member created and has made available. This is also an open source project. He created something called a policy reporter which takes this policy report and also provides a nice graphical ui on it. He's also got the ability to push this to griffana, loki and elasticsearch and create other notifications, but really nice example of how you know. You can now view this graphically.

C

You can share this inside a single cluster, so just wanted to highlight that so, if you're, looking for a single cluster tool to you, know visualize these policy reports and even create notifications, when these get created definitely check out this policy reporter project- um and you know we're- there's- also work in progress by the way to take more, give or no metrics uh and push these to.

C

You know to prometheus, uh which could then be, of course displayed in various uis and dashboards like grafana and others as well, but this is more focused on the policy report. The other work that we're starting now is to build to push engine metrics and engine statistics out as well all right. So let me stop there.

C

I know we have about five minutes left for the hour, so I would love to see if there's any other questions, thoughts, comments uh that we can help answer um and you know again like there's plenty of documentation and if you want to reach out to us, uh feel free to reach out on the kiberno slack, uh which this is the on the kubernetes slack, the kimono channel itself.

A

Well, that was one thing I was actually noticing. Is that your documentation is awesome so um congrats on that, because I think that's one of the things that drives communities um and really helps people adopt. We have a couple people on um the call that that had um some questions, uh paul murray, um if you want to pop yourself out of mute and onto the screen and kirsten newcomer.

D

Yeah, uh so uh I heard a lot about pods. I didn't hear whether you can write policies around um custom resources, so like say that I have a custom resource for my own bespoke controller that creates pods. um It contains something that's like pretty close to a pod spec. Can I write a uh kyber, no policy on it. Absolutely.

C

Yes yeah, so one of the things right from the beginning kivano has supported is you know, also full custom resources and um it does help if the custom resource schemas are structural.

C

So, if they're structural, what kiverner can also do is, can validate the various paths and fields for that custom resource policy, if they're, not that validation doesn't occur, but caverno will still apply the policies.

D

Okay um and how about if I have like an aggregated api, can I write uh policies against apis that another api server might bring in.

C

So you can make calls to an aggregated api server right so through the api call construct, if you, for example, if you want to pull metrics things like that, that would work. If there are resource definitions. Yes, then those can still be, you know, looked up and then policies can be applied to those okay.

D

All right, thank you.

A

Sure there's one question chris kirsten in the chat mikey's asking: um do you need a cni to enforce the policies.

C

So for network policies: yes, if you're generating a network policy, you will still need a cni to provide that runtime. You know kind of to make sure that you know the right. Segmentation exists on the network layer, but for other policies like pod security, etc.

C

Those are applied directly with the api server and kiverno itself will block configurations that are violating you know the the policies you set.

E

Person take it away sure thanks. Oh, but my cat mike had a mikey had a follow-up issue. Yeah go.

A

Ahead is the mutate policy in cash until validate is run.

C

Yes, so there is a there is a ordering in you know the admission control, so um the validate will occur. You know um at the end, so all of the mutation logic will occur and then once that's done, then you get a chance to sort of validate, there's also a way to reinvoke admission controllers so caverno by default, when it installs itself, it tries to be the last admission controller to receive so there are, you know there are some customers who will use both opa and kiberno.

C

um You know, for various reasons, and in that case you know you could still run one particular policy and then register to re-receive any mutated results.

E

Great take it away thanks, so I I had kind of a question about network policy generation as well. um How do you inform the generation of that network policy? Are you using uh config data to inform that or is there uh you know, or is that optional kind of? How do you decide on on? What's going to be in that policy, that's generated right.

C

Yeah, so the few things right so the trigger to generate the policy could be the creation of a namespace could be the setting of a label or as a setting of an annotation itself. So one pattern is if you're using. If you want some variations- and you want to control- you know like, for example, uh what exactly gets generated you could use labels and based on labels generate, you know, have templates for different types of network policies, and that would be yeah. One quick way of you know of changing that.

C

You can also do things like, because caverno can look up, the namespace can match namespace selectors. You can say that if for certain namespaces and if there is an annotation on that namespace, then based on that, maybe you want to trigger a different uh network policy. So then you would have two different generate rules, one for each. So you know a few different ways of managing those kind of variations and handling that.

E

Great, thank you. That's helpful um and I know we're pretty much right at the top of the hour. um I'm actually I have two questions, but but I'm going to pick one of them do you have thoughts on uh kind of policies or ways that we as a community, might move forward to kind of apply policies to respond to events in the runtime.

C

Yeah great question right and something that we have been thinking about, there's been discussion also in the policy working group about what other triggers submission controls and configuration changes, of course, are one one trigger, but it would be very interesting to also have a set of you know, defined run-time triggers uh there's also discussion.

C

um You know about um authorization checks right, so somebody in the community was asking about. You know that there's a self-subject review request that gets sent out uh from the api server when when there's an authorization check, so you know for having some more granular policies on that.

C

But yeah to your point like if there's other runtime events, um even those could be potentially used for triggers, but it's something that it's not supported right now in kievano, but we're very open to that and interested in hearing more about the use cases and how that could be standardized.

E

Great thanks so much! That's it from me all right.

A

Well, thank you guys for coming today. It's it's wonderful to have these upstream talks um on mondays, because I I really didn't know that much about caverno. Before this. That way I was pretty opa centric in my understanding of policy management and such so it's really helpful to to have the context set, and so I think everybody appreciates that, as well as jim awesome, um deep dive and demo there today too so um well definitely you're in the sandbox.

A

Now, um yes, the road ahead, more more production users, more people using it more feedback on it. Hopefully incubation and graduation into the you know the real world today, um sometime soon absolutely and we'll definitely um get you back on as it matures, and we get further down the path and um congratulations on on getting into the sandbox and getting it to this state again.

A

um If you're interested in this topic, these guys are pretty active in some of the sigs in the cncf as well as I, as I mentioned earlier, the documentation is rock solid. So I'm good on that. That's as a community person, that's one of my key uh tests, whether we can um keep something going forward um and definitely when you get a new release, new features, new functions, reach out to us, ritesh and jim and and we'll have you back so um good work. Good luck and thank you. Thank you.

A

Thanks again for sharing the information with us today,.