 Thank you very much, and thank you for having me. So my name is Joe Betz. I am a contributor to SIG API machinery, and I've been contributing to a series of features over the last couple of years, which covers what I'm going to be talking about. So I'm going to be focusing a lot on a feature called Validating Admission Policies, which we introduced in 1.26, and we're trying to bring to beta in 1.28. I'm going to be showing you a lot of code examples, and so here's the first one. First I'll tell you what it does, and then I'll kind of walk through how it works. So what we're going to try and do here is we're going to try and validate that the environment label on a namespace can only be one of three allowed values. The examples I picked are Developer Sandbox, Test and Production. Now before this feature, you would have had to use a webhook to do something like this, but now you get to do it all on a single YAML object. It works kind of like a webhook. You start with a set of rules that say I only care about namespaces, and then you add a match condition, which in this case says I only care about namespaces that have an environment label. And then lastly, you use a programming language called CEL to write a simple expression saying what you want to do. So this CEL expression says that I only want the environment label to be one of the three allowed values. CEL stands for the Common Expression Language, and we're going to be using it quite a bit. So let's quickly jump through this example. We need to register it in our cluster, so we would apply this YAML code to our cluster. We would also create something called the binding. The binding connects the policy to our cluster. You can't see it here, but this binding is configured to enforce this policy. The other options are to send a warning or to record it to the auto log. So here's an example. We are creating a namespace, and we're going to use kubectl to do that, and since we've put in invalid value, you're going to get an error back immediately showing what went wrong. Let's try another example. So we're going to extend that idea, and we're going to say we want to require that every namespace has two labels, an environment label and an owner label. This is what the CEL expression looks like to do that. Pretty simple. If you try it out, if you forget to add one of the labels, now you're going to get an error back saying, oh, you missed a label, you need to go add it. In this example, you can see that I've also used CEL to customize the way that that error looks. So not only are you using CEL to enforce your rules, you're also using it to construct the messages that you send back to your users. Let's take this example one step further. So what we're going to do now is we're going to imagine that we've got a cluster and we're going to allow every developer in our cluster to have one namespace. And that namespace is going to be their username dash sandbox. So we can do that again. Here we're also checking namespaces. We only care about namespaces where the environment label is set to developer sandbox. So we set that as a match condition. And then we set our two validation rules. One requires that the owner label be correctly set, and the second one requires that the name of that namespace follow that rule that we set up for ourselves. And that's it. You could take these examples much further. A good exercise for the reader is to try and set things up so that only approved users can create test and production namespaces. You can do that only with CEL. You don't need a web book for this. And you can do that by performing an authorization check in CEL. So if you want to take it further, that's a good example. I'm going to show you just a couple more examples in the last minute I have. This example is requiring that every deployment that I put in my cluster has a liveness probe on it. You could take this example much further and require that the liveness probe have a very specific format as well. That could be really useful in a cluster where you know that all your containers have a liveness probe at the same location, and you want to make sure nobody forgets to put that in place. Here's another example showing us using CEL to ban the use of a deprecated API. We're saying, I don't want anybody to use the volume type and give repo. It's an old volume type in Kubernetes. It's deprecated. You're not supposed to use it anymore. So what I'll do is I'll reject any request that I try and use it, and I'll send a nice error message back telling you what you can do instead. And that's my very last example. You could also use this to do something like limit wedge container registries users can use in things like pods and deployments. This is a simplified example because I've kind of hard coded the registry into my cell, but you can with this feature put into a config map or into a custom resource, a list of allowed registries, and then you could load that in and check it against your incoming requests. I'm out of time. Thank you so much. If you have any feedback, I'll send you to the slide, and I will hand it to the next.