 If you can hear me good, I'll put it in the chat. Yeah, perfect. Everybody, welcome. We had some connection issues, but we are alive now. Quite OK on schedule, even though a bit late. But as always, welcome to Cloud Native Live, where we dive into the code behind Cloud Native. I'm Annie, and I'm a CNC as ambassador, as well as a senior product marketing manager at Camunda. And I will be your host tonight. So every week, we bring a new set of presenters to showcase how to work with Cloud Native technologies. They will build things, they will break things, and they will answer all of your questions. So join us every Wednesday to watch live. This week, we have Chip and Shuteen here to talk with us about examining hot security admissions. Another exciting thing that's happening in Cloud Native Sphere is that online programs calendar is open for Q3, so you can book your live streams and others now. And as always, this is a official live stream of the CNC app. And as such, it is subject to the CNC code of conduct. So please do not add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all of your fellow participants and presenters. And now, I'll hand it over to the speakers to kick off today's presentation. Hello, everyone. Chip, are you ready to kick us off or? Hi there, sure. Shuteen, can you hear us? Are you with us? Would you like to kick things off? Or should I go ahead and kick us off here? All right, I'll take that as a yes. Go ahead and do that. So hi, folks. My name is Chip Zoller. I'm joined by my colleague, Shuteen Zhao. We're from Normada, but we're also Coverno maintainers. And we're here to talk to you today about pod security admission, a really cool feature that ships in Kubernetes 1.23 and forward, how that works, some things to be aware of, how it can work for you, and how it can play with some other things like Coverno and maybe some other tools that are out there. So join us as we kind of explore this really interesting topic and see how it can work for you. So the first thing is to really talk about what is pod security admission? So pod security admission, if you're not aware, is the new built-in controller that's a replacement for the pod security policies that have been around in Kubernetes for a little while. But as you may or may not know, pod security policies are currently deprecated and they're also being removed. And that's a very important point, removed in the next version. And so pod security admission is a way for you to provide security for your pods by enforcing actions against them, warning and auditing, as we'll see. And without having to add anything else. And it improves in a lot of ways on the pod security policies that were in use prior. And the, but the super nice thing about pod security admission is it's built in. And there's not really anything that you have to do to get started as long as you're using one of the compatible versions of Kubernetes other than to label a namespace and to go. And so some of the things that we're gonna go through are looking at what PSA is, showing PSA in action, some things to be aware of that are, some of which are in the docs, some of which are not quite that visible, but things to be aware of. And we're gonna do demos of these things and also how PSA can work with something like Coverno, what values that you can get from those and some closing points and then some Q&A. And so, so Shitting, if you're back with us and you're able to hear us, feel free to, feel free to kick us off and just launch into what is PSA and then showing it in action. We might still be experiencing some issues or Shitting, can you hear us? Hey, Chip, yes, I can hear you. Can you hear me now? Yes, we can hear you. Okay, let me share my screen. Oops, share the screen right now. Okay, let me know if you can see that. We can see it, but we see the stream deck now. Okay, awesome. So, sorry, I just lost the connection for a moment and I'm not sure if Chip has already introduced the standards and security of Micheal or, so I'll try to set up some context for our session today. So, as you know, Coverno, he's introduces the pot, sorry, are you trying to say something or? No, the floor is yours, Shitting, you can go ahead. Okay, let me stop sharing and see if that makes you better. Right, so before we dive deep into the demo, I just want to set up some context for this session. So, sorry, I just lost the connection for a minute. You know, a little bit. Okay, it seems like we're having some connectivity difficulties here with Shitting. So, why don't I take over here until we can get those resolved? So, as Shitting was saying, so pod security admission is built in and is the replacement for PSA. So, let's actually start and look at an example of this and how this works live and what goes on in this. So, in the case of PSA, and let me just get a quick confirmation that you're seeing my editor here. Looks like we are. So, in PSA, what happens is you have namespaces that can be labeled with a label, which is able to instruct the API server what type of behavior we want to have happen. And so, in PSA, there are three behaviors that we can get. We can audit a result or a resource, which means the resource will be allowed, but it'll show up in an audit log. We can warn, which means the resource will be allowed to be created, but if it's in violation of a policy, and I'll speak about those in a second, then it'll just show a response back to the user that there's a problem, but it's been allowed, and then there's an enforce. Enforce means that a violation of a resource that's being submitted will be blocked. Now, PSA is a technical mechanism, but it implements what's known as the pod security standards. And the pod security standards are a codified way or a set of guidelines or controls that tell you basically what pods shouldn't do. So as the name implies, it's for pods, and it really has a bearing on the security of the various fields in it. So for example, things like making sure that you do not run as root, making sure that you have a set comp profile that's within specified parameters. Pod security standards are just a way to describe the behavior that should occur, but PSA is a mechanism. It's a technology that's built in now to the API server starting with Kubernetes 123 and allows the pod security standards to be enforced and without anything added to them. So if we take a look at some of the namespaces I've got here, I actually have a... Audience question as well if we have time to grab it. Yeah. Yvonne asks, where are there more cons than pros? So we'll actually get to that in just a little bit and I'll explain kind of what they are and why they're labeled as that. And then you can decide whether that kind of makes sense or not. But first I just wanna show what the actual pod security mechanism looks like in here. So if you take a look at some of the resources here, I've got some good resources and some bad resources. And so let's take a look at what a good resource that passes what's known as the baseline profile looks like. So I'll go and let's show this one. So a good pod in this case, there's no other fields that are specified. And in the baseline of the pod security standards, this is going to allow to be passed because there aren't any fields in this that violate the controls of that baseline. However, the next level up is the restricted profile which places many more restrictions on the fields and what their values have to be. And in which case, this may not necessarily pass the restricted one. So if I wanted to implement pod security standards in my environment, then although I've already set up an admission control file, which I'll get to in just a second, I would just simply need to label a namespace with the behavior that I want and also the profile. So let's create a baseline namespace. And let's just do this. And let's label baseline with, we're going to enforce for baseline here. So what we're showing with this is we created a new namespace and we want pod security admission to be enabled. And by the way, it's already technically enabled in the API server, but when we label a namespace, we're effectively saying, hey, go into action and do something. And so now we've declared that we want to do two things. One, we want to enforce, which means that anything that's in violation of a level should be blocked. And two, we specify the level as the baseline. And so that's what we've done here. And so if we take a look at a pod that passes baseline, we should be able to apply this to the baseline namespace and allow it to pass and now does pass. And that's probably not all that interesting because you can probably do that even without creating the label that's on it. So let's modify this in such a way that it won't, that it will be blocked. So if we go, I'm just going to pull up a deployment that I have and let's see what I'm specifying. So I'm going to do security context, privileged, true and go to my container here and add this in and we'll save it. And we should be able to reapply this and see what happens this time. So now if I have notes called good pod, it should not be a good pod anymore. And so now we see the message that came back from the API server and this is blocked by the PSA controller itself directly error when creating this pod, it's forbidden because it violates the pod security baseline latest. And then we have a privileged container that's being requested here. So privileged equals true and privileged is required to be false in the baseline profile. So in other words, it's being blocked because we told it to enforce the baseline profile. We told it to enforce it and so that's exactly what it's done. It's kicked it's back and it's not allowing us to create that. So one of the other nice things about PSA in addition to just simply applying a label and go is you can apply multiple labels to a namespace and get a union behavior. So it's not just an either or type thing but we're only enforcing here but let's say that we wanted to warn as well. And so I could simply just add another label to this same namespace and rather than enforce let's do warn and I'm actually going to change it up to do I'm gonna remove enforce and just do a warn instead but let me also add audit. So what I'm gonna be able to show here is that the namespace now has two labels. One of those labels, if I show them one of those labels is to audit at the baseline and the other label is to warn at the baseline. And so rather than blocking a resource it's doing two things because we're getting a union behavior. We're saying allow the resource to be created if it's in violation but warn the user which is a nice capability. And also too, we want that to be shown up in an audit log which is a separate entity that has to be configured in advance under the API server which unfortunately don't have time really to show that but we should be able to now try and apply the same resource. Again, this is still in violation and we saw this resource blocked just a minute ago but we should at least this time allow this resource to be created and we are not able to do that. And let's see why did I mess up. Let's mess up here. Baseline, we're auditing and we are warning. And okay, I must have a lag or something in my environment here. Okay, well take my word that the warning actually works and it does show something back. So that's the behavior that we would get. That's a nice thing to be able to combine enforced behavior with other behaviors including warning and audit. And so really that's as simple as pod security admission is you label a namespace with a combination of the profile that you want, the behavior that you want and optionally if you wanna pin things to a specific version of those pod security standards because remember that PSA implements PSS and nothing more, then you'll be able to do that and you can pin it to a specific version. So for example, let's say that we're on 1.24 which my test cluster running under K3D is but when you upgrade, you wanna be able to pin the version of the pod security standards at 1.24 so that when you do upgrade, you have the chance to gently move developers and other users to what the new standards are by continuing to do things like enforce the version that's pinned at 1.24 in giving the ability to do things like warn at a later version. So it's nice in that you can prepare developers and prepare your users by having certain behavior enforced on a namespace but also giving them the opportunity to look at or let them be warned about behavior that will potentially in the future be blocked. And so I showed this on to or want the same profile baseline but really where this shines is where you have something like baseline that's being enforced but also you're warning at restricted. So restricted is encompassing the baseline profile plus new controls that are in restricted. So what this allows is for you to enforce baseline which is really just a great idea to do anyway across the board but also warn about anything that would potentially be blocked and restricted. And so you can then tell users, hey, we're gonna let you create this but FYI this will be blocked when we either enable this on this namespace for the restricted profile or in other namespaces that restricted may already be enforced, it's not gonna be allowed. So that's the capability of operating at the namespace but one of the common things that comes up is, well, hey, that's great but I really want this to apply to my cluster in wholesale fashion. And so how do we do that? Well, pod security admission requires this admission configuration file to be created in order for you to specify what the default behavior and that's specified here should happen across the cluster. And so the way this typically works is you create the admission configuration file as I've done here, you put in whatever that you want, including the exemptions and exemptions can be one of three things or three of three things, usernames, runtime classes and namespaces. In this case, I have those commented out but once you have the file created, then you pass it as a flag to the API server when you're building a cluster. And in that regard, the PSA has already turned on but it adopts the settings that are in this file. So let's just see this quickly in action. So I'm gonna go and delete that baseline namespace and I have some other namespaces here but they haven't been explicitly labeled but this admission control file is in effect. And so what this should then result in is one of these bad pods would be blocked in other namespaces. So let's just see what other namespaces I have and I'll just create a new demo namespace. And so I'll go back to my bad pod here, which I guess I already had one so I didn't need to modify my good pod and I'll go to my namespace and apply bad pod baseline and so we see here that the pod is being rejected because of that admission configuration file. I have a cluster wide configuration that's applying. I did not label this namespace as you saw, I just created I didn't assign a label to it and there's the proof for that other than the metadata.name which is a default and a mutable label. So we're getting that behavior cluster wide and that goes for any namespace that I just created as well as future namespaces, existing namespaces. So that's a really nice thing. And so with that admission control file, it's really easy and useful to be able to enforce PSA across the entire cluster. You can put different levels here. So I'm enforcing it baseline and under the enforced version I'm pinning to latest. And so I talked about version pinning. So rather than saying an explicit version like 123 or 124 just saying latest, which means whatever the version of pod security standards that you have with the version of the API server itself that's the version that we wanna enforce. But again, you can mix and match. So I'm doing auditing and warning for baseline. So you can basically extend this and see how you can take it and get the behavior that you want from a global perspective. So that's a little bit about PSA and action and showing how that works. Again, it's pretty simple, which is a good thing because you can either just label namespace and go. And if you need cluster wide application you can do that with a submission configuration file. So let me pause here and see if there are any questions that came up and just scanning real quick. Not so far questions, but if anyone has any please leave them throughout the presentation as well or we would have a bit of time in the end for Q and A as well, so looking forward to them. But currently still no questions, so far. Okay, good deal. So with that, you got a little bit of taste of PSA and you might be saying, well, this is great. I wanna use this. And indeed it is great and we think that you probably should but we do also fall out some of the things both comparing the pros and cons so that you can make a decision for yourselves keeping in mind real world operation of clusters. So the first thing, as I've shown it's super easy to get set up. In fact, if you're on 123 or 124 there's nothing that you have to do. It's already there. You just label the namespace and go. It's integrated. It's built into the API server and this is one of the biggest pros is that you don't have to worry about submitting resources to another admission controller and that's better from a security standpoint but it's also super fast and that's a really good thing. It embeds the pod security standards. So I talked about at the beginning the idea of pod security standards being a collection of concepts organized as controls where each control specifies the type of behavior that you should have. And so PSA embeds that. It's a technology that enforces that behavior but there's no bolt on. There's nothing else that you have to go and do. It's already intrinsically there and that's super convenient. It can audit resources. So, and I didn't really show this from an audit perspective but if a resource was in violation and you had the audit label applied if you had created an audit log and that's a little bit out of scope for this discussion but Kubernetes API server has an audit log capability that you also have to create an advance with a configuration file and you can do things like send the audit results to a file or you can send it out to another location but anyhow, if you've done that then those audit results will show up in that audit log. Now that's good and bad as kind of talk about but you can do that and that's super helpful. It's also super helpful that PSA allows you to warn users that is let something pass but just let them know, hey, FYI we're warning you but this resource didn't actually pass the profile that we assigned. So that could just be like a preemptive mechanism or that could be, hey, FYI, a month down the line it's not gonna warn, it's gonna fail. So that gives users some feedback to know whether the resource that they're submitting needs to be tweaked and how that gets tweaked. That's kind of a separate thing but version pending, I talked about this but the ability for you to basically lock in the version of pod security standards that you want now to ensure that even if you upgrade you still get consistent behavior until you're ready to move and you moving is just simply a matter of you labeling that namespace. That's really helpful because predictability is a good thing. It helps us reason about behaviors. It helps us troubleshoot behaviors. It helps communicate with users better. So those are good things. However, falling out some of the things. I have a question as well as we have time for it. So how can I live with PHP? How can you live with PHP? Not sure I fully get that one. If you can clarify, Sudhir, be glad to take that one. Yeah, waiting for clarification from there. Okay. So going into some of the cons here and really these are just FYI things to be aware of because you wanna operationalize this probably in a production environment for your users and not tinker around in it with a lab like that's always a good first start, but it's just pods as the name implies. And this is coming from pod security standards or pod security policies. It's only pods. Now pods represent the lion share of the workloads that go into a cluster. But as you're all aware, there's way more resources in Kubernetes that you have to worry about than just pods. And that's even before you start getting into custom resource definitions that your ecosystem tools, by the way, which everybody has to use, which they bring and also maybe custom resources that you bring from your own organization. So pods are a great place to start from a workload perspective because pods are the atomic unit of scheduling. They run containers, containers represent the workloads. Like that's great. But there are more than pods and you do need to be cognizant of more than just pods. But for pods, PSA is a great thing to get started with. It's just the pod security standards. This may not be as apparent, but as I mentioned, pod security standards are a codified set of controls that the Kubernetes upstream organization puts together. That means that you can't create your own custom control and have that enforced. You get the pod security standards. And also it may not be apparent, but this is one of the things to call out. You either enforce or you either take action on the entire control or the entire level or you don't. In other words, you can't have, let's say that there are eight controls within baseline. You can't say, I want those six, but not those two. Doesn't work that way. You either get all of the profile or you get none of it. There's really no middle ground. There's really no way for you to add custom controls to that. Oh, question. How does pod security and mission controller interact with other solutions? Like, you jump in the gun. I'm about to get there in just a minute and gonna show some useful things. So let me finish through these and then we'll actually get there. No mutation. So if you're familiar with pod security policies, one of the abilities that PSPs had, which was really cool was that you could mutate pods and get the behavior that you want. And PSA, not so. It's just validation. So your validation is either, is falling into one of those three categories. You're enforcing your warning or you're auditing, but you're not materially changing a pod. So be mindful of that. This one is fairly important to know and that is enforcement of pod controllers. So your deployments, your stateful sets, those aren't getting enforced if you have a policy or a label that is enforcing that. And so let me just show real quickly. So I've got a restricted namespace that's here and this is labeled with enforce restricted. And so let me try and create a deployment that's bad that I know is bad just to demonstrate this. And I've got a bad deploy restricted here and it's bad for the restricted profile because it doesn't have anything in it that does things like say run is non-rude, et cetera, et cetera. So if I try and create that in the restricted profile, and this is a deployment, it says cool, happily created, busybox is created, awesome. So everything worked, right? Let's get pods. Oh no, there are no pods. Wait a minute, it told me it created the deployment. So we'll do it, get events. And so now we can see here that it's actually blocking the pods that are coming out of the replica set. So as you can see from the subject on which the event was created, the event isn't created on the deployment, which means if you do a Q control, explain on the deployment, it's not gonna show anything. So anyhow, just wanted to point that out that although warning does work, although audit does work for your enforce, which was what you really want for a lot of the behavior, then there's not, you're gonna have to figure out what you do. And typically the answer is, will you wanna additionally label it with warning that way that somebody sees something? And that's good, but what if you're creating this as part of an automation process, as far as the pipeline or something, no one's gonna be there to see that. So anyhow, that's one thing to be aware of is that there's no enforcement for pod controllers. I use the deployment, same type of thing with stateful set, job, et cetera. Those are all pod controllers, it doesn't enforce. This is fairly minor, but messages aren't configurable. So the message that you get back and that users see regardless of whether that's a warn or an enforce, it's not configurable. However, the warning message is pretty descriptive and it is helpful, but that's something to be cognizant of. You can't really change the message. Seeing audits honestly is a little bit painful. I know I didn't show it here, but going through the audit process in order to see resources that you wanna allow but show up involves a multi-step process. You have to create an audit log. You have to have a configuration for it. You have to determine where those audits are going. You have to do this across all your control plane members, you have to pass a flag. And if you're using a PAS, whether that's on-premises or out in the cloud, oftentimes you can't do that unless you have done it on day one at the time of cluster build. So kind of similar to PSPs in that it's really not an effective retroactive change. You can't just really flip it on. If you can, great, then you can do that if you're running like a bare metal cluster that's provisioned with Cube ADM or whatever you wanna do, but it is a multi-step process to go through to see those audits. And that goes without saying, or maybe it doesn't, but I'll say it, that you can't really see them in the cluster. Like, I just looked at events, which is a Kubernetes resource type from the cluster because they're available in the cluster, but when you create an audit log that's accessible to the API server, you don't see that in the cluster. It's not, they're not resources that show up from in the cluster. So you can't have, for example, your developer team that's creating resources and their resources that are in violation, but your operations team or your SRE team who's responsible for looking at those and maybe coordinating or communicating with them from inside the cluster going, oh, hey, Samantha created this deployment and it failed and we wanna let her know and whatever the case is. You actually have to go and find the audit log in the control plane or wherever that's exported. The cluster-wide policy requires a special configuration. That is that admission control file that I mentioned here. And so I kind of talked about that a little bit earlier. Same similar thing with the audit logs in that you have to pre-create the file, has to be available on the control plane, you have to pass a flag, all that type of stuff. Exemptions, they're kind of limited. You have three possibilities. You have usernames, runtime classes and namespaces, but one of the things that we see in the Coverno project is that very, very often people need more fine-grained exemptions than that. They need things like pod name, they need other stuff. So anyhow, be mindful of that. Can't use this in a pipeline from the perspective of like a separate tool that's decoupled for it. So a lot of us do use pipelines when we're offering resources in order to go from resource creation down to deployment. And very often you wanna know before that resource begins to trickle down to a cluster, well, is it gonna work? Is it in violation? Unfortunately, unless you stand up an actual Kubernetes environment, and there are many great ways to do that, kind, K3D, others, it's difficult to know whether that's gonna work for pod security admission because there's not a standalone tool that you can just say, hey, you know, tool like here's a resource, check it out. Does it violate or does it pass that profile? It's not really a thing. And it just goes without saying, but this is fairly new. And it does take a little while for this technology to mature. And that comes with people that are using it. So not reasons to not use it, just reasons to be cognizant of these things and see if this is gonna work for you. And so let's from there, take a little bit of comparison, let's look at a little bit of comparison against Coverno and how this works in comparison to PSA. And so that you can kind of decide, which one is attractive and it's not necessarily an either or it could be a both and I'll show that in just a second, but Coverno works on anything, it's not just pods, any resource that you can create. You can create any custom policy that you want to, it's not just limited to pod security standards. Coverno does have mutation support. So if you wanna change pods, if you wanna change any other resource for that matter, you can do that based on your own custom policy. Coverno does offer the pre-built pod security standard policies and I'll install those in just a second here so that you can see, but they are the exact same controls that are enforced in PSA. There's not any, it's just the Coverno implementation. There's not any difference as far as you get, this behavior with things that are in Coverno or other things and you get different behavior with the same behavior, it's just how it comes. Coverno has a resource called a cluster policy and I'll show that here in just a second. Cluster policy applies as it kind of sounds to the entire cluster without having to create a file that is specifically known only to the API server. The exemptions, which I think I'll also show can be super easy and very granular. In fact, you can get down as far as container name and a union of bunch of different things. So container name, environment, labels, and annotation values. Basically, whatever mechanisms are already there in Kubernetes, you can define an exception for that somehow in Coverno. Coverno automatically applies pod policies to pod controllers through a nifty capability called auto generation rules. That means that there's no allowing silently of a deployment that's in violation, but blocking of its pods. You write a policy for pods and your pods are in violation, you create a deployment, deployment has a pod template, that template is in violation as well, the deployment's blocked as well. So you can see instantly, not only are my pods blocked, but people don't create bare pods. Pods are almost always created by a higher level controller. You wanna know if that controller is gonna work or not. Coverno automatically can block that if you want a different behavior, can do that. Audit results are easy in that audit results show up in an open standard called a policy report, and that is available as an in cluster resource. So if you have a resource that's in violation of a policy, you can see that violation as an in cluster resource, and that's cool because you can now decouple who writes policy and who sees policy results. So you can have that separation between your policy authoring team and your SRE team that can go and see those violations. It does have a CLI that is standalone. So you can know in your pipelines, is this resource gonna pass that pod security policy or that pod security standard profile? It'll tell you immediately before it even hits a cluster and it's got some broad version support. So PSA, it's on by default and 123 forward. There is a separate admission controller that you can deploy from earlier versions, but Coverno works back, there's versions that work all the way back to 114 or something like that. And that's good because not everyone can upgrade it, even the reduced velocity of three releases per year. So I see a question that's come up here. Is this native Kubernetes, which version is it in? So pod security admission is in 123 forward enabled by default. So if you're on Kubernetes 123 and forward, it is there. It is enabled by default. All you do is assign a name, space, label and go or other things if you want to. So quickly hitting on the cons because, wanna be open and transparent is really this is about showing what the capabilities are and then you determining for yourselves like how this capability can be used. And we do think that PSA should be used and that it's a positive step. So Coverno, just like every other tool has its own cons and that is it's an add-on. It's an admission controller that you install additionally. Now, no matter how easy that is, nothing is as easy as being built in like PSA is. So that's something to call out. PSA is a set PSS is a separate group of policies that you install. You know, that's just that comes with the nature of the beast but the PSS policies are fully built and can be installed with a helm command which I'll show in just a minute here. Unfortunately, Coverno right now does not have warnings. It has an enforced and an audit capability. We're gonna try and address that in the future. So that's something to be aware of. Block resources aren't in audits but they are however written to events on the policies themselves so that you can get visibility on that. And if you do need to do version pinning, you just have to have more policies and rules. So, you know, that's probably not the biggest deal because the Coverno community would typically provide those. So anyhow, let's take a look at some use cases that we can use PSA plus Coverno and get some useful behavior. So the first thing that I wanna show is, so we wanna use PSA but maybe we also wanna use Coverno or something else that has mutation capabilities. But in this case, I wanna automatically, like I don't wanna use a cluster wide admission configuration file. I do wanna do this on a per namespace level by ad hoc labeling a namespace but I really don't wanna label every single namespace by hand. Well, that's perfectly fine. How about let's let Coverno add those labels for us? Let's let Coverno add the labels that we want for the given pod security admission based on the policy. So I have a policy here that's gone to anytime a namespace is created and I can gate this in a lot of different ways by, you know, making it specific to names but I'm gonna assign the baseline to be enforced and I'm gonna warn at the restricted level. So let me just apply this cluster policy and I've already got Coverno installed I didn't mention that but now I have the cluster policy installed let's create a new namespace and let's see what happens. We'll just create namespace who and we will show labels on that and as you can see Coverno has written our two labels for us automatically. So that's super nice in that whenever you're provisioning new namespaces and you can create multiple rules that do this based on like a pattern for example like if you have like prod dash star or something then Coverno can respond accordingly. So that's the first thing and I can apply a resource to that but improve that it works but I think that you'll take me at my word that it does. So that's the first thing, you know use Coverno to apply labels to a namespace that you want but let's say that you're already using that admission control file and I'm already using this in my case. Now, one of the things I didn't talk about is that you can set a label called privileged and privileged is basically allowing users to do whatever they want in that namespace. So we think of pod security admission as a mechanism that you increase enforcement of by having nothing and then making it more restrictive but you can also go the opposite direction which is you're more restrictive from a cluster perspective but you wanna go privileged on a certain namespace. Well, Coverno can help us in that regard as well because let's say that we do need, you know as part of our exceptions we do want the cluster to have an admission configuration file that applies to the entire cluster but we also need to create some namespaces that have that privileged label because we're doing some things in there that we need maybe temporarily or not some privileged access so that's what we're doing but we're saying here with the exclude that everybody who is not a cluster admin is immediately prohibited from doing that. So let's create this cluster policy and so I've created a user in this cluster called foo user and foo user has the permission to create namespaces but in Kubernetes RBAC there's no way to distinguish between one who's able to create namespaces and one who's able to create namespaces with certain labels. So this is where Coverno can come in and sort of augment the ability of PSA in providing more of that fine-grained exclusionary control. So if I try and create a privileged namespace here and let me make sure that I don't have privileged so I don't have privileged here so I'm gonna try and create this namespace as me as a cluster admin and it's allowed me to do that and so I just created a privileged namespace that has the privileged label which is basically gonna allow anything that I wanna do to happen inside of that. So let me rename this cookies because I like cookies and let's try and create the cookies namespace which remember has that label set and we don't really want that if you're a cluster admin as foo user. So I'm gonna apply the same thing as foo user actually before I do that, let me just prove that foo user has the ability and you can see here to create that namespace. So it does. So I'm gonna try and create this as foo user and that shouldn't have happened that I did have it as enforce. I'm not sure what is going on internally with that but anyhow, it should block it and it did block it and prior to this, this is always the fun thing with live demos as you never know what's gonna happen. So anyhow, that's one policy that can be used. You can scope down and prohibit certain activities from happening based on whatever type of exclusions that you want and also see from the last example here, you can use PSA to enforce baseline and you can use Coverno to enforce the restricted profile in your cluster. So if I go and install the restricted policies, the restricted pod security standards. And so I talked about installing the pod security standards from a Coverno perspective and this is how I'm doing it. It's a simple Helm chart, Helm install Coverno policies. I'm setting the profile to restricted and I'm also setting it immediately to enforce. So that's basically, I'm still using baseline in my cluster but I'm using Coverno to enforce the restricted profile. And so I can now do things like create or prevent the creation of a bad deployment in restricted in a namespace that does not have the, does not have the label assigned. So if I do, for example, can foo apply F bad deploy restricted, we've seen here that Coverno is providing all of these messages back and we are not setting any of these things. So these are all messages from Coverno here. As you can see from Coverno, the validate web book has denied all of this. So you can combine a lot of these things together and get the exclusions that you want, enforce things where you need them. And as things become more known, you can remove those exclusions, you can gate them down, et cetera, et cetera. So hopefully this has provided some info on that and on how you can use the two together. And so just to go over some closing points here for opening up for questions. So first thing is to acknowledge that you will have exceptions. Everybody has exceptions, no exception. So almost no matter what you're doing in any environment, the first thing that you're gonna have is exceptions. So what type of flexibility do you need? With PSA you get three options, username, runtime, class and namespace. And if that is all that you need from an exception standpoint, great. You should definitely look into that because it's super useful. However you will have to create that admission configuration file. Securing pods isn't enough. So right out of the gate, you're signed up for more than just PSA. So do you wanna use one or do you wanna use two tools? Just keeping in mind that you've solved for pods and that's a great and necessary first step and everybody should do things like enforce the baseline. But you gotta think longer about what other things are happening in my environment? Where are we? How do we operate? Who's using it? What are they permitted to do? You probably need more than just pods. And so PSA can be that for pods and you can choose something else for not pods. But typically, we see this over and over again and that is everybody's using pipelines some way somehow because you really wanna know the resources that I'm building and I'm allowing my users to build. What's gonna happen when that lands in my PCI cluster? What's gonna happen when that goes out to my cluster that's in London and I'm in the US and we're just rolling a new application out? You probably wanna test those things. And so maybe in your existing pipeline, it's easier to use a standalone tool because you can just drop that in rather than build a full-fledged Kubernetes cluster no matter how that may come. So do you need to think about that? But also, as I mentioned at the outset, there's a difference between deprecated and removed. PSPs are removed in the next version. And so if you're still on PSPs, definitely look at PSA, but keep in mind that as of 1.25, they are gonna be gone. And so with that, I'm gonna stop sharing and I will be glad to take any questions and let me just stand here and see what we have. I think people might be typing their questions now. So yes, it's Q and A time everyone. So time to ask all of those burning questions now. We have a four-minute timeline left for them. So good time for those. While we wait, everyone to type away their questions. I have a question as well. So what are the most common security failures you see in Kubernetes workloads? A lot of the common security failures that come in with Kubernetes workloads are just not doing things according to those pod security standards. So having problems with letting your containers run as root, and that goes for building them and also running them, things like ensuring that you're not using privileged mode. Most things don't need privileged mode. A lot of the failures that happen are due to some of these misconfigurations that tools like PSA can catch really quickly. And so I mentioned it multiple times, but regardless of whether you use multiple tools or not, at the very least, you should enforce baseline. Just do it, just enforce baseline, get started with a good base. You will avoid a lot of those misconfiguration and security issues if you just enforce baseline today and then select, excuse me, selectively as you begin to go forward, start looking, excuse me again, start looking at restricted and seeing if that works for you. But keep in mind, like I mentioned on the closing points, you're gonna have exceptions. So it's probably not gonna be a case where you can just cart blanch, flip something on, even in a whole namespace, because you're gonna have things like sidecars that need to be injected from your service mesh or your secret storage system or some bespoke stuff that you're doing. So anyhow, long answer to the question, most security failures just come in not doing some of these simple things from the very beginning. Great. The Jingdong had a comment rather than a question, but thanks so much for the presentation, super cool. So that's really great to hear. Thank you so much for that comment. We have two minutes left. So this is final call for questions if anyone is typing away right now. But while we see if anyone hits that enter button now, is there any final words that you wanna tell everyone to like resources that they should check out after this or so? Yes, thanks for that. So as I mentioned with PSA, go look at the documentation. There are some really nice tutorials that are out there and then try it out in your environment and see how everything works. Play around with the admission configuration file from a cluster wide perspective, get a feel for that and then kind of make the determination for you based on how you operate, your organization operates what your requirements are, what your constraints are, is that gonna work for you? And, but at a very least start by enforcing, getting some quick wins by enforcing baseline to enforce some basic hygiene in your clusters. And then if you wanna look at additional tools like Coverno or something else that's out there, great way to get started with that is the pod security standards that as I showed, Coverno will have the ability to deploy in a fully bundled manner. And also if you take a look at the policies library that Coverno has, I think there's over 180 sample policies that are out there. So it's a great way for you to learn, how Coverno constructs policies, but it's also a super easy way for you to go and just grab something that works for you and either just turn it on immediately or perform some minor modifications and start getting value from it. So thank you all for allowing us to talk and hope everyone enjoyed it. Perfect, thank you so much. Then it's time to wrap up. So thank you everyone for joining the latest episode of Cloud Native Live. It was great to have a session about examining spot security admission. So we really also love the interaction. Thank you for the great comments as well as questions today from the audience. Thank you so much. And as always, we've been using the latest Cloud Native Code every Wednesday. So next week we will have a session on enhancing your GitOps experience with flux tools and extensions. Thanks for joining us today and see you all next week.