Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2022, 12 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kyverno Introduction And Overview - Chip Zoller & Dolis Sharma, Nirmata

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Kyverno Introduction And Overview - Chip Zoller & Dolis Sharma, Nirmata

Speakers: Chip Zoller, Dolis Sharma
Kyverno is a Kubernetes-native policy engine which allows for validation, mutation, generation, and software supply chain security use cases all without requiring knowledge of a programming language. In this session, we will introduce you to Kyverno and explain and demonstrate in detail all of its capabilities. We will also share future roadmap plans, how you can get involved in the community, and provide all the resources you need to start solving your use cases. Kyverno was accepted as a CNCF Incubation project in June 2022.

A

It is time to get started, so this is the caverno introduction and overview session. If you thought that you were coming to something else, I'm sorry to disappoint you, but I hope that we're able to Delight you. Instead, my name is Chip zoller I'm, a technical product manager at nermata and I'm joined by my colleague, dala Sharma.

A

And I'm also a caverno, maintainer and I do have a couple questions for the audience just by a show of hands. If you can just look up from your laptop from just a second, so first question: please raise your hand if you're running kubernetes in production at least one way who is running kubernetes in production, all right hands down, raise your hands again. If you are using some policy for your production, kubernetes cluster, who is using some policy?

A

Okay, cool good to know all right hand it over to Dallas.

B

B

Later on, dig deeper into types of policies and some interesting use cases; okay, so starting with that.

A

Wrong direction.

B

Okay, I'm sorry.

A

B

Okay, thank you cool, so, let's start with why we need policies today. So if I have to give you a general example that why policy you can look at example that using a single Cube Kettle command, how can an ad? How can a user get access to the entire host, so he can run just he or she can run just a single command and they can get access to the entire host. There might be different reason. This might be occurring.

B

First, is that we might not even know that this is a bad part and we are not supposed to run it. There might be other reasons like we don't have any guard rails in this environment, so these kinds of requests are not blocked.

B

There are no policies that are running that is actually blocking or auditing these kind of requests and then, as more people get involved, they have different backgrounds, they have their own travel information that they come up and they don't know what to do and what not to do- and of course, kubernetes is hard. So someone who is new to kubernetes will find it difficult to get everything in the first go so yeah we need policies.

B

We need policies to make sure that such kind of incidents, our scenario- doesn't happen or is blocked or at the least at least audited. So what can policy deliver? Policy can Define laws and it can Define some guard rails that can help you to block such kind of request. It provides a proper check and it makes you up. It makes you visible to your security posture of your cluster. So what you can do is using policies. You can Define some rules.

B

You can Define some guardrails and make sure that the policy security posture of your cluster is good. Once you have these policies, you can centrally control them and when you're applying them, you get consistency. So you are applying these policies and you're getting security, wise consistency for across all your environment.

B

Once you deploy policies, you'll get violations, you'll get a report, you'll see, what's failing, what's not working! This will give you more visibility into your cluster into your environment and then policies can or perform automations. So policies can do couple of things they can automate couple of things we'll we'll talk about such use cases deeper in next slides. But, yes, that is one more interesting things. Policy can do and all of this actually the important thing is deploying policies. What policies can deliver us. It sets certain expectations of others.

B

So if such kind of requests are blocked, people know that okay, these are the expectations and we are not supposed to deploy something like that which all in everyone saves your time, it's reliable and it makes the security side of the cluster very easy.

B

So a little bit about keyword, no kivarno means govern in Greek, it's a cncf incubated project. It's a policy engine which is a kubernetes admission controller. It's natively built for kubernetes. That means it is easily integrated for kubernetes. You do not require any programming language to create a policy or write a policy. So if you know kubernetes, if you're good with yaml, you understand a yaml, the syntax, the format of it you're good, you can write your policy.

B

There are a lot of policies available, but you can start writing our policy from day one and it's most popular pillar by star in the policy engine, and we have the largest policy library of a policy engine. So if you go to keyword.io and if you see the policies we have, we have a huge amount of policies. Therefore, maybe every use case so why? What the overview and what are some keyword, features on an overview level. So we have validation.

B

Qr no, can provide you validation, mutation and generation with the help of these policies, so you can set up some rules and you can validate with the help of the policies you can validate those rules against with what you're applying. So it provides you validation on the Clusters. It provides a mutation to the existing resources, so you can say that, okay, when this happens, this is the trigger. It should muted some resources that are existing in kubernetes, so it provides mutation.

B

It provides generation, so you can create your own trigger in the in the form of policies and it can generate when that trigger happened in kubernetes cluster. We have some image verification that kivano can provide you, so it really helps you in verifying your images and then it generates a report that is that is created centrally. When you deploy keyword node. That means it tells you that what is violation What are the violation.

B

uh What policies are are boiling listed with all kind of like what deployments are being violated to What policies, so you get more visibility there and then we have kuberno CLI, so kuberno CLI. You can easily point it to a cluster and maybe do a dry run before you are deploying any kind of deployment you can easily integrate it into your CI CD pipeline. So before you do a deployment, you can actually verify it, whether it's it's security, wise good or should you need? You have to do any changes.

B

These are some use cases. Real life use cases that kuberno can help you with. So we have seen some um some in in the initial slide. In the last couple of slides. We see that there was this using Cube cuddle.

B

You were able to deploy a bad pod and you can get access to the host and you can do all all sort of things so keyword who can help you block such kind of requests, even who can help you only that, but can deploy best practices, policies PSPs in your cluster and you can block such kind of requests or you can at least have a audit that okay, these are some of the pods, and these are some security. Why? It's not good parts that are running in your cluster. It provides fine grade R back.

B

That means a user with a role May create secret with the label such kind of use cases, something that Kevin can help you with. It helps you in your cost control, for example, use cases like you need to track particular cost. uh Particular Cloud resources like your load, balancers or maybe your EBS, and you have to generate a cost based on the tagging, so keyword helps you in automating.

B

Qr helps you in tagging those resources running in your kubernetes and also it can help you with use cases like okay, the service type with load balancer should only create a load balance in AWS which helps you in the cost. Overall, it helps in Ops automation, so use cases like seeing the config map whenever a new certificate is generated.

B

It helps you in these kind of automation, by generating new Resources by doing some kind of automations for you, and then you might have a use case where you are using a shared cluster where there are multiple applications running on the cluster, so you need multi-tenancy. So you might need that. Okay, when I create a namespace five different things should be created automatically. It should be I. I, don't have to do anything. It's just the trigger has been namespace once the namespace is created. We need what we need. Network policy.

B

We need quotas and all those multi-tenancy resources and in kubernetes automatically created and set up for the developer. Kyuno can do that for you using generate policy, and then we have supply chain security use case. So how do you make sure that you're signing your image and then you are validating it with what cluster is consuming, so kuberno can help you in these kind of complicated use cases as well, and there are more to that.

B

But these are some standard use cases and top use cases that you can achieve using kivano, and here there is a sample policy on the screen. Now, if you see this policy you'll, if, if you're familiar with yaml, you can actually read that policy. So it's quite simple: it's quite easy to read. You know that it's it's standard yaml, just like a deployment or a pod yaml, so you'll see there's an API version. There is cluster I'll, not I'll, not go entirely.

B

Maybe but yeah you'll see that this policy is applied to a pod, so you have a rule over there. It's applied to a port and then there is a message that will be thrown whenever the policy is blocking a pod, and then there is some kind of patterns that are its policy is validating. So this is a kubernet policy that you can see and all these validate policies are something similar, so they are easy to. You can write it there easy to customize as well. So these are very, very simple.

B

That's that's basic yaml over here, and these are this- is the application kuberno component that will be deployed on your cluster, so you'll see that there is an API request and keyword no actually interrupts that API request based on what policies you have applied and it it can validate mutate generate according to that. So there are some validating web hook configurations. There are mutating webhook configurations, and then there is cluster role and cluster role binding. So if you want to strictly tighten the kubernos application permission in your cluster, you can do that.

B

You can change cluster role. Cluster role, binding- and you can restrict keyword, knows permission to a particular namespace or if you want to tighten it further, there are custom resource definitions. There is config map, so you have a lot of features that you can customize using config map and there is service account secret. The standard stuff. The kubernet deployments over here comes with their additional Single part, but it comes with h a so. If you want to deploy keyword, Now using ha you can go with that.

B

If you have a standalone cluster and you just want single pod, we have both the flavors of kubernose, garment and then there's a service, of course, so yeah these. This is what the application looks like and that's how the components are deployed on your cluster, and this is a sample policy structure.

B

So we have already seen in the last slide that that was a validate policy, so it looks similar, that's the standard of how how a policy is going to look like so policy can have one or more rules and it has a match and exclude condition. So a match condition is going to match with certain kubernetes resources. For example, there is namespace, there is also this entire group it can match with and in exclude. If you have some exceptions like okay, my keyboard should should ignore couple of maybe namespace couple of User Group.

B

You can put it in the exclude section and then it have different Clauses after the rule it can actually it it performs the Clauses and the Clauses it can mutate, it can verify it can validate, it can generate so muted is going to mutate. Existing resources generate is going to generate you validate, is going to validate with that and verify image is going to verify whether your images are signed and the same images are being consumed by a cluster.

B

Okay, so I think um before the session will be taken by chip and he'll dig deeper into the type of policies and some pretty interesting use cases over to YouTube all right.

A

Thank you Dallas. Thank you all right. So, let's take a look at in a little bit more depth. Each of these capabilities that caverno has and Dallas kind of laid out from an overview what they are, so validation rules validation. This is probably the most popular type of rule if you're using any policy engine today. This is your quintessential yes or no response. Here's a resource, I have a policy that says it should look like this. Do you allow it or do you not allow it? Coverno obviously, does that quite simple.

A

This occurs during the validation admission phase. So when the API server sends a request to something based on the definition of a policy, it goes through a life cycle or a tube. If you will and two phases occur, the mutation phase occurs first and then the validation occurs. Second, all the validate rules occurs. Surprise during the validation phase, which is the last phase before it's accepted into a cluster. This is the most common rule type.

A

So all of your things, when you're thinking about pod security, making sure that pods and containers therein don't run as root, making sure that you don't run host path, that you don't have a user. That's number zero. All these types of things. These are all these all fall under validate rules.

A

There are two failure, behaviors that coverino supports today. The first type is called audit. This is where we will allow the resource to be created if it's in violation of the policy, but we will tell you about it in a policy report which I'll get to later on policy report is just another standard, kubernetes resource. The second action is in force. This pod, or whatever the resource is custom. Resources included, fails the definition of the policy. We will deny its creation, and there are two styles that you can write.

A

Validate rules in one is an overlay style expression and that's the example that Dallas showed a few slides ago. This is the mo what most policies in the validate rule, or indeed, most policies written in caverno use a simple expression or a simple overlay style. This is very similar. How customized does it because we're actually using customize in some cases under the covers where it's, where you specify the portion of the resource in which you're interested in matching, not the entire representation of the resource?

A

Just a portion of it second way to write validate rules is with a deny condition so conditions in kubernetes we're all familiar with those key operator value caverno has the same constructs using a deny statement. You can use these Expressions to achieve even more power by pulling in some other Advanced capabilities, which we don't have time to cover, but two styles of a validate rule that you can write with plenty of flexibility to achieve any of those use cases.

A

Mutation capability caberno, is at mutation capability right out of the gate and it's very, very mature. This is, as you may or may not know, be the ability that defines the modification of a resource so going back to the phases of admission review. This occurs first in the mutation phase, so when a resource comes in, if there is a policy that says you should mutate, this mutation will occur.

A

There then get shunt to the validation phase later on, where there may or may not be a policy to apply additional validations on that mutate rules like validate can be written with an overlay style. That is, if you're, only interested in applying a specific portion of the resource. You can do that by specifying with with overlays, which is the easiest and simplest way to go about doing it or you can use standard 6902, Json patches, and these are non-adulterated Json patches Cabernet supports those perfectly well and using those json's patches.

A

You can do things like remove values or change values in a lot of different cases and by the way, all of these things that we're talking about- and this is a common question that comes up work for custom resources as well as standard kubernetes resources. So it doesn't matter what type of kubernetes resource it is coverno can validate, it can mutate, it can verify images stripped away from it can generate it, etc, etc.

A

Mutate also supports the ability to mutate existing resources, so you have existing resources that are in the cluster, and you need to provide some sort of retroactive mutation against them, rather than performing all new mutation based upon an event on that would be that a create or an update. Caverna has the ability to Via a policy definition apply retroactive mutations based upon your design, the generation rule type. This is one of the most popular rule, types in caverno and one of the things that really differentiates it from a lot of other policy engines.

A

Governor has the ability to create new resources of any type based upon a trigger that you define happening in the cluster. The source of that can be either a clone.

A

Here's an existing resource, that's somewhere in the cluster I, want you to put it over there in number of times or it can be defined in the policy in what's called a data structure and in the data structure you define I, want my resource to look like this, including things like variable, templating and expressions and all sorts of things that can go in there and then, when that trigger occurs, it will create that resource upon that definition and whatever the the whatever the defined Target is.

A

It also supports synchronization, so it can watch the source resource, be that defined in the policy or the source resource in the case of a clone, and if that changes, it can immediately synchronize those contents down to the downstream locations. This also enables things like tamper resistance. If somebody tampers with a downstream resource and synchronization is enabled Governor, we'll see that and immediately revert the resource back to its previous state.

A

This also works on existing items. This is great, for if you have Brownfield environments, which everybody does you've got existing name spaces, and you want to generate resources into existing name spaces without having to manipulate them or even worry about creating new namespaces caverna can do that as well. Based on the same simple policy definitions.

A

This is obviously great for multi-tenancy, and indeed this is one of the most popular uses of it, where even if you're, not using true multi-tenancy you're using soft multi-tenancy for things like applications, if you are using multi-tenancy for separate teams or even separate customers, caverno can be a full namespace provisioner and generate all the resources that you need in order to get that namespace into production quickly, image verification.

A

This is caberno's ability to verify the image signatures in an oci registry of the images that are being proposed to be run in the cluster coverno internally uses the cosine project from sigstore anybody heard of Sig store. Recently yeah, it's been been a lot. Cosine is used to sign the images coverno uses cosine to verify the signature of those images. This is integrated. All of these things that we're discussing are integrated directly into coverno. There's no bolt-ons, there's no additional things that you install.

A

If you don't want the behavior, you don't get it as soon as you want it. All you have to do is write a policy. It enables the behavior. This also supports things like attestation checks. Anybody here attesting to their images in any way, shape or form right now.

A

So a couple brave souls all right, hopefully at some point in time we get to do more things like provenance, but but anyhow we're ready for that. It's it's already there and cabernos to force the ability to check at the Stations of any predicate type, even custom predicates, and you can verify any portion of the attestation payload using any form of expression that caverno supports, of which there are many all of this works with any oci registry. There's no isolated list of these, only specific ones.

A

If it's an oci registry and it conforms to the oci spec kubernet will work with it, pull those images and look at the image signatures and attestations on them, and you can do some complex, multi-way checks, so any Keys all keys at least one or at least two keys. So you can do things like my entire organization is required to sign all images, but if they're going into a PCI namespace. Additionally, the security team has to sign off on those images and based upon whatever policy design that you want.

A

It can ensure that anything that goes into that namespace maybe gets two signatures that they have to validate. Otherwise, it's just one so policy reports I talked about this on the validate slide, but policy reports are a standard, Custom kubernetes Custom resource that shows the results of validate rules placed in audit mode.

A

So if a validate rule is in audit mode and a resource violates a policy, the resource will be allowed to create, but it will log that in a policy report, this is an open standard from the kubernetes policy working group. This isn't some esoteric standard that we created just to give you yet another CR. The kubernetes policy working group defines a standard policy report structure, that's by the way adopted by several tools that are out there in the ecosystem and what this is.

A

What this enables is the separation of those who can write and see policy and those who can write and see policy reports they aren't crushed together in the same thing, so somebody has to parse out the results of the policy they're cleanly separated, so you can set you the roles that you wish can separate, based on whatever desire that you want uh policy report comes in two flavors, a namespaced policy report and a cluster-wide policy report, things that are namespace scoped appear in a namespace policy report, those that are cluster scoped, for example, node or some other custom resources will appear in the cluster policy report policy reports are written in two modes admission review: that's if the policy is in audit mode and also what we call Background processing mode, if you create a rule with background processing, enabled caverno will, on a scheduled basis, go and check.

A

All of the resources that pertain to that in an existing cluster and if they're, in violation, we'll write that into a policy report, so you can do things like Drop in a policy in audit mode and get an understanding of the disposition of the resources in that cluster. Without any admission requests having to come into it, results are pass, fail, worn error and Skip again. These are all defined in the open standard of the policy of the kubernetes policy. Wg and coverno supports all of these CLI uh caverno has a CLI.

A

It allows you to test policies outside of a cluster. The way this works is in two primary Fashions. This allows you to check against a Define manifest, as in I, have this policy I have this or these resources and I expect this result to occur when these are evaluated. If that result is not achieved, it'll be deemed a failure or you can just YOLO and say here. There's a policy.

A

Here's a resource, tell me what happens and it'll give you the output and, by the way that works with things like mutate and generate here's a policy. Here's a resource give it to the CLI. It should come out if it's up, if it matches to it, it'll show you the full representation of the generated or mutated resource.

A

This is obviously great in CI CD pipelines, because now you can shift left and put in the CLI so that your authoring experience is the same and you're able to reason about that process all the way through to the running in the cluster. So whatever the CLI reports, you can do things like deny your.

A

You can fail your PR- and this is a very common use case and in fact, in the documentation, we have a sample GitHub action that this is all plumbed up for you can go and copy and paste it right now as a way to get started, and it's simple enough where you can use it in any project it it's very standard. This is a go binary. It's available as a q, Control Pro plug-in via crew via Homebrew, lots of other installation methods, very easy to get started uh and to install it.

A

This is part of caverno. This is not an isolated utility that was sort of whipped up to evaluate caverno's language separately. The code that executes in the CLI is the same code that executes in the web hook. It's just in CLI form factor all right, so some things that are new in caverno 1.8. For those that are not aware, we released 1.8 uh technically a couple weeks ago, but we had the release blog that we put out there earlier this week.

A

There's a new pod security sub rule. How many of those here are familiar with the either pod security admission or pod security standards? You know what I'd note I do not mean PSPs, pod security, admission or pod security standards, pod security, admission being the technology which implements the PSS standards. Okay, so pod security admission is a new feature. As of kubernetes 1.23. It reached stability in 1.25, which was the same version in which pod security policies were removed.

A

So for those who are not aware, pod security policies are gone, that is not deprecated gone in 125. the same libraries that Power Pod security admission, which is the kubernetes replacement for PSPs. We pulled that Library into caverno and made a much simpler abstraction using this pod security sub rule. So you can do things like us, apply the entire restricted profile of the Pod security standards in one single rule.

A

Another thing that we added in 1.8 is yaml Manifest, signature verification, so I talked about the ability to verify image signatures and attestations from the Sig store project using cosine. They also have a sub project, which is the signature and validation thereof of yaml manifests. Caverna was brought that feature in and allows you to sign, yaml manifest and verify. Well, caverna won't do the sign-in converter will do the validation of those yaml manifests before they're allowed to come into your cluster and also allow you to do things like exclude certain Fields.

A

So, for example, if you want to sign a deployment to prevent, ensure that tampering does not occur from the time that that is signed to the time that that's run. But you want to allow users to only change replicas. You can Define that in a simple gamble-based policy and caverna will validate that signature before allowing it to run. None of that involves any programming language on your part.

A

uh Caverno also now has the ability to clone multiple objects in a generate rule, so, prior to this feature, generate was sort of a one-to-one mapping. You triggered on one resource and you got one resource, but now this allows something like create a new namespace and, in the same rule clone out 10 things. For example, you can do that in just a single rule.

A

Definition now uh get Ops friendly, pod controller rule, autogen I didn't talk about autogen, but caverno has an ability whereby you can write a rule for a pod, and we will automatically translate that for all of the standard, kubernetes pod controllers. That means that you don't have to write separate rules for deployments. Demon set staple sets, jobs or cron jobs. Caverna will automatically do that if it sees that you're only trying to match on a pod. In this version we moved that auto generation capability from the spec object up into status.

A

So those of you that are using git Ops tools to deploy your coverno policies, you can do that very simply without having them go to war or providing any exceptions. We overhauled the reporting system. uh We completely rewrote the reporting system to be faster and more accurate uh lots more. There open, Telemetry support for those of you. We already had Prometheus support. Now we added open Telemetry uh grpc is what's supported right now. We didn't talk about the James path system, those that are familiar with Json path.

A

There's a similar system out there called James path and caverno completely brings in the James path system, but we also create brand new filters that are only endemic to caverno and in this release we added two more filters: random: the ability for you to create a randomized string based upon a regex pattern that can be as simple or as complex as you want.

A

So, for example, if you want to generate an API key, if you wanted to generate a pod hash, caverno can do that internally, with no other logic that you need x509, decode, the ability to decode an x509 certificate and parse out the yaml in any policy definition. So, for example, you can now do things like I want to know in a policy report. Perhaps if any of certificates that are in my cluster are going to expire in the next 30 days and I invite you to get involved, caberno has over 3 000 Stars.

A

uh There is a contributing guide. We have good first issues that are labeled and we keep those up to date, documentation you can find at carverner.io our policy Library, there's over 230 sample policies and that grows, and these are for ecosystem tools. Far beyond just kubernetes itself, so istio link or D we've implemented their best practices, Argo flux, assert manager, some AWS I, don't even know all of them, and it grows all the time.

A

Also that policy library is Community Driven any of you can write a policy maybe for a tool that you don't see for your own use case. We will gladly accept it. We will work with you to test it and make sure that it's solid and then we'll add it to the library and make sure that everybody can access it. We have a weekly contributors meeting. We have a quarterly end users meeting.

A

We have two channels that are on slack one: uh one is on kubernetes slack with caverno and caverno Dev on caverna there's about 1400 users and on cncf Slack, and with that I want to thank everybody for coming and we will be glad to take questions. Dallas has the mic. Please wait for Dallas to bring the mic to you. Raise your hand if you have a question we'll be glad to take that with the remaining time.

C

Hi, thanks for the talk, uh is it possible to write a policy for one resource where it's evaluated against another resource in that same name, space.

A

Absolutely okay: caverna has the ability to do API calls to the kubernetes API and um get any resource that you want, and it has a rich variable system that allows you to store that as a variable to perform transforms against it and to substitute that variable at basically any point in the policy that you want to any other questions, one down here or one over here. Okay,.

D

Thanks for the talk um can caverno uh as part of his triggers send a web hook to a different service and have that service send back yay or nay.

A

No, it does not do that today. That's an interesting use case. I come come and talk to us in the caverno booth I'd like to understand a little bit more about your use case.

E

um Thank you for the talk. uh Is there a way to put timeouts when I have too many rules and just takes too long to validate something.

A

Like that yeah, so caverno exposes a field uh on the policy on every policy where you can set the web hook, timeout behavior, that you want, in addition to the failure Behavior. So if you want, if you'd rather fail open for some reason, you can configure that on a policy. If you want to change the web hook, timeout from the default I think it's like 10 seconds to the maximum which the API server allows us 30 seconds. You can easily do that. Those are just the additional two fields that you define.

F

Hello, thank you for the talk. So I have two questions. One is I'm new to cover. No, so first question is how much different it is from Oppa or uh you know we hear about our open policy agent. All the time and the second question I had is like, can uh Governor create attestations, for you know, images or any of the other artifacts that you might have yeah.

A

So two two different questions very different questions. The first is: how does it relate or differ from Oppa in Opa, with and without gatekeeper?

A

um Caverna was written from the ground up only for kubernetes caverno is not a general purpose policy engine at this stage and that's a conscious design decision, not a mistake or not something that and the reason that we wanted to do. That is because we wanted to shift the burden away from users of having to write and maintain a programming language, even if you're capable of doing that. We want to shift that burden so that that process is easier. It's easier to maintain it's easier to reason about.

A

Maybe you who are capable of writing a programming language can collaborate with your security team who is not, and everybody be on the same page. You can reason about policies and also you can use your existing tools to manipulate and even write those policies. So if you want to use customize to do things like add additional exclusions, add additional preconditions which we didn't talk about, add additional conditions to a deny statement.

A

There's no block scalar with a bunch of yaml, underneath it that you have to manipulate. You can do that with existing tools and processes that you have today. The second question is: is Governor capable of creating attestations? No Governor does not create attestations, nor does it sign images. It is in the runtime path of ensuring that the attestations and signatures are present and are valid. Based upon your definition.

A

Any other questions, oh.

G

Hi um at what point are we doing too much yaml and we should use a real programming language like? Is there a a recommended.

A

G

A

um uh I, don't know that so I I'll, I'll start I'll start with one thing: anecdotally, I'm very involved in the in the caverno community. Maybe those of you who use caverno have probably seen or maybe received help from me from slack I'm, also very involved in the kubernetes community in a number of different ways.

A

In the time that I've been I mean at this point in time, listening to real world use cases from thousands of people, I only know of two use cases that caverno has no way to accomplish both of those are tracking for completion in the next version. So at what point? What? Where is the inflection point between trying to Wrangle yaml and having to go to a programming language? And the answer? Is that really depends on you, your skill set and what you're trying to achieve?

A

If you have highly highly complex policies with a bunch of I, I can't even come up with a concrete example, a lot of conditional checks that need to just be totally off the wall that might be better purpose served for a policy engine. That's capable exposing a program. Framing language I will also say that we have on the roadmap and we are trying to work towards the ability for caverno to support a language like Q, Lang or cell, or something like that. That's not today, but that's we're looking at that for tomorrow.

H

Thank you. You actually touched on something. I was uh very interested to see the the cosine implementation there and I can really appreciate that um cosine does have the ability to kind of do some policy evaluation itself.

H

How does it overlap with what you're doing kind of, like uh you know, for a use case uh being able to validate Providence on an image with in Toto, attestations, yeah.

A

So so conferno does support, checking the in total attestations, but the one of the differences and I I will not pretend to be knowledgeable to a certain extent on on their admission controller, but I believe that theirs requires for attestation checks use of Q Lang to be able to validate them. Caberno does all that without Q Lang today, with simple expressions using James path or just simple patterns. We have time for one more question and then the moderator is going to kick us out. Okay,.

G

The trying to understand uh two parts one is given that you have multiple policy documents that might match a given resource. Is there any ordering constraints? Yes applies.

A

Yes, good question, so two two important constructs about caverno and this is important to take away. There is no possibility in caverno for one rule to usurp or countermand. Another rules only serve to extend the failure domain, but within a policy there is an application order. If you want that behavior you can Define I want to start at the top and evaluate down, and only one or the first one much Matt must match, or all of these must match. You can change that behavior.

A

You can leave it default, it's up to you, but no matter what Behavior you choose. You can't have one policy countermand another. So there's we close that security hole off the.

G

Related question was given that you can have these generated policies. There becomes a kind of a nasty debugging infinite Loop potential in there or something could generate a policy. A generator could generate a bunch of other resources which go through Kevin and generate more resources and and on and on it goes. How do you debug something like that?.

A

We have we have internal Protections in logic built in to catch situations like that, so it doesn't cause a runaway train. I I, don't have full details on that, but but we we've thought of that problem. We've experienced it and we we have some logic that will prevent that loop from occurring all right. Thank you. Everybody for coming to this talk will be available here for additional questions.