 Hi, welcome to the open source summit. I'm Rachel Leakin and Jamie Duncan is on here as well. We'll be taking you through bridging security and reality with Open Policy Agent. So let me tell you a little bit about myself. I'm Rachel Leakin. I'm a field engineer at VMware. I've been on the team for the last couple of years working on Kubernetes and in the cloud industry in general. I'm also a USPTO inventor. And also part of my role here at VMware is promoting Kubernetes content through Cube Academy. So I'm an instructor on that as well. And also creating content for our customers through the cloud readiness program, which we have here at VMware where we create content to help customers develop through their DevOps processes, such as as you'll see today going through OPPA and developing policies using OPPA. Also, I'm a big Chelsea soccer fan. So that's my favorite team. And I try to watch them whenever I can. So today I'll pass it on to my colleague Jamie Duncan for telling me about himself. Awesome. Thanks, Rachel. Oh, we jumped one slide too far. All right. We're going to get control of the slides here in just a second. So a little bit about me. I'm one of the staff architects at VMware on the on the Kubernetes team. I'm coming out of the sort of Heptio acquisition and all of the open source initiatives going on inside VMware right now. I've been working with Kubernetes since before it was called Kubernetes and containers since before they were called containers. That's the nicest way I could come up with of calling myself old without calling myself old. Rachel is a patented inventor, which is amazing. I don't have anything near there. Probably the coolest thing I've done is I did write a book on OpenShift, which is a different Kubernetes distribution came out in 2018. And in my spare time, I'm a big F1 racing fan, which Rachel doesn't get. And I'm working on that. And in a rabid amateur gardener. There's our backyard is full of things that don't often grow. So like Rachel said, we're going to be talking about OPA or OPPA, Open Policy Agent. And where it lives primarily in a Kubernetes ecosystem. And I want to preface that with saying OPA and they prefer that like the community prefers it is pronounced OPA instead of OPA. And so we're going to I'm going to try my best. I'm an OPA person, but we're going to say OPA. OPA is not limited in any way, shape, or form to just Kubernetes. That is where it's seeing a lot of uptake and a lot of adoption for what it can do. And it is not, it is a general purpose tool. And we'll get into that a little bit more. We'll touch on that again when we start talking about the bits and the bytes of what OPA does. But for today's presentation, we're going to take the old who, what, when, where, why trope. And we're going to apply it to OPA. It's pretty simple, but it's also pretty effective. This talk is not a 400 level graduate course in how to do crazy things with Open Policy Agent. One of the things that when Rachel and I were putting this together, that's fun. Doing crazy things with, with cool tools like Kubernetes and OPA. It's a lot of fun to see how weird you can be kind of how weird can I Kubernetes. But when we stop and talk to our customers, when we talk to the people that are bringing these tools into production to do work for end users to do work for customers to generate revenue to make this stuff happen in reality. Weird and crazy doesn't really apply. And what we run into is they really need good solid fundamental knowledge of when it, because when it doesn't work the way they think it should, they need to understand how to go about figuring out why. They win, you know, every computer on the planet breaks, and they need to know that, you know, they need that fundamental knowledge of what these tools do at their base to to understand how to unbreak them when they do. So we're taking the old journalistic trope of who, what, when, where, why, and how, and we're applying it to OPA. So why is Open Policy Agent? You know, what purpose does it serve? What use case does it handle inside Kubernetes that Kubernetes itself doesn't do? Who is Open Policy Agent? We'll take a couple of minutes and talk about the community around OPA or OPA and where, where that information is coming from, who those people are. And then we'll talk in, well, what is OPA? What is Open Policy Agent? And that's where we're going to get into the bits and the bytes and how it's designed and everything that we need to get to how is Open Policy Agent, which is the live demo that Rachel's going to be running for us. Rachel's the smart one, so she's going to be doing, she's going to be doing the live demo. I believe we have paid off all the live demo gods. I'm pretty sure we have. So cross your fingers for us, even though we're recording this, it will be a live demo. And then, as always, we'll have some conclusions and a call to action. So why is Open Policy Agent? Why you need OPA in your Kubernetes security strategy? And we're going to talk for just a minute about how Kubernetes does security. How Kube does, how Kube secures your things. And security starts all the way down at the bottom of the operating system inside the Linux kernel. And that's where the Kubernetes security posture begins as well. Kubernetes uses things like SE Linux, uses things like POSIX, which is, you know, how file systems are created and handled inside Linux. And it uses these technologies to make sure data from one container in running, managed by Kubernetes is not able to jump and be accessed by another container that doesn't have proper permissions. And this stuff has been tried and true and has been trusted sometimes since the 90s with SE Linux and is securing some of the most sensitive data on the planet and doing it very effectively. So we have all of that going forward. So we were pretty confident in the Kubernetes security world that if I put a piece of data in container A, that without explicitly allowing it, the underlying Linux infrastructure is not going to let containers B, C or D go see the data in container A. And we've got that pretty well locked down. But that doesn't give us everything because we do want some levels of access. So Kubernetes comes out with has out of the box now a tool role based access control is built in. And there's also a concept called pod security policies. And RBAC lets me set exactly that access controls based on users based on service accounts for all of the different objects inside my Kubernetes cluster. So I can create a service account and service account X can have access to anything that is got a proper label on it or anything that belongs in the specific namespace or anything across the whole cluster, depending on what I want. And RBAC in Kubernetes is a little unwieldy. So pod security policies have been created to provide a little finer grain access control and a little more programmatic access control using those RBAC principles and pod security policies together. And that doesn't get us all the way there. So we have all of the security kind of moving up the stack, but also in any kind of container initiative in any kind of Kubernetes deployment, you have to have pipeline security. You have to have good container hygiene and we call it container hygiene because you don't want dirty things inside your container images. And that is primarily handled by an entire industry of third party tooling stuff like Clare and SonarCube and Dynatrace and Falco and there's a whole laundry list of tooling that gets you to that point. And they do things like scanning what's inside my container images to see if they're known vulnerabilities. They do things like running integration tests inside my container images like SonarCube to make sure that what I'm doing, you know, the way I've built my container is in compliance with the way I've said my want my containers to be built. And there's a whole raft of tools that get into the pipelines and do all of those things. All of that's great. And that if you're employing all of that today inside your Kubernetes infrastructure, you're doing a pretty good job. But there are some holes left and some of those holes can be dangerous. There's some gaps in the security model because there are things that the code inside Kubernetes simply can't do. And some of those gaps can be dangerous. And they can be dangerous in ways that you don't automatically think of. And that's really where OPPA's value shines through. So let's get into that just a little bit. So OPPA helps us close those dangerous gaps. And the primary gap we're talking about with OPPA and the way it works inside Kubernetes is how do you stop something that's not against the rules of your RBAC setup or your pod security policies and doesn't violate the rules of SE Linux. But it violates your business rules and it violates your best practices. And that's sometimes that's obvious stuff. Like how do I make sure and make sure not just by telling the humans not to do it but make sure programmatically that in my Kubernetes deployment it is impossible for me to deploy development code into a production namespace. We've all done it. Like anyone that's pushed that has made production pushes before has made the mistake of pushing the wrong thing into production at some point. And that's why maintenance windows are these large scale events at three o'clock in the morning on a Saturday that have 400 people in a conference call because we use humans to prevent that. Well, OPPA is a policy driven way to do the same thing. And other ones are that are a little less obvious. Things like making sure all of our images are deployed from approved registries. And that's an easy one to forget is once we start building a container image we start putting all of our stuff inside a container. We forget that that very first line in the Docker file says from something and if that where it's coming from is not a safe approved place especially when you start getting into regulations and compliance rules and regs like in the healthcare industry and the government in the financial sector that gets really important. And it gets really important to make sure that we that all of our data all of our personal information all of our monetary information all the government information that shouldn't be out there doesn't get out there. And then you can also do things that are just good best practice inside a cloud that is hard to manually verify. And the last one on this list is like making sure all pods have resource limits defined. For a human to verify that they would have to go look through the YAML that deploys every pod in their Kubernetes system in their Kubernetes deployment. And that's onerous and prone to failure. Well, we can write a policy using OPPA to make sure that's the case. So OPPA gets deployed inside Kubernetes and acts as a policy engine. And that policy is based on any of the attributes of all of the objects inside Kubernetes. So you can deploy you can build policies based on what the object is. And I think that's the demo that we have here in a few minutes. You can deploy you can build policies based on what namespace something goes into. You can look at the annotations of an object and build policies based on what's inside the annotations based on what's inside what labels or selectors are built into the object. Anything any attribute of an object inside Kubernetes I can write a policy using OPPA and we'll get into how we write those policies here in a couple of minutes. I can use those all of those attributes to build a policy to make sure the way I want my software to be deployed is the way it gets done. One of the great example that had never dawned on me until actually it was Rachel that was telling me about it with a customer she was working with was they made sure that you couldn't deploy a load balancer into certain places in their infrastructure. Because once you have a load balancer deployed into a namespace, then that's the front door to get to my data. And instead of having to go looking for those things, I think built an OPPA rule and OPPA policy that just wouldn't let it happen. That's an incredibly, you know, an incredibly insidious attack vector a very hard one to figure out that you can just stop with OPPA right out the box right out of the box. So who is open policy agent? And the little Viking helmet with the horns is the logo for OPPA for open policy agent. But taking a quick look and we're not going to spend a ton of time on this but we do need to sort of acknowledge who is building any open source project. Because you define an open source project's health by its community. And that's the way you understand like is there's a lot of time and a lot of our effort on the team that Rachel and I work on is looking at these all of these products that are out there and doing the research and talking to the people that are using them and figuring out if they're going to be around in five years. If you're about to spend a huge amount of time and effort to bring a new technology into your into the way you do business into the way you do you do Kubernetes and it disappears in 18 months. It's a lot of wasted effort that you then have to turn around and repeat. So looking at the community of any open source project that you're about to bring in is a worthwhile endeavor. So OPPA was started by a company called Styra. And Styra is the logo in the center of this slide and is a security company. So it's an interesting thing and it may be obvious when you start looking when the live demo during the live demo that it's a very security centric language. For example, when you write an OPPA policy, you start with the assumption that you're going to deny and you write the policy around a deny first idea and it's and it folds very easily into that minimal that zero trust model that everyone is striving to achieve inside Kubernetes. The work that Styra is doing around OPPA inside Kube and inside other technologies that like I said at the beginning, OPPA is not limited to Kubernetes. It's not a Kubernetes only planet. And one of the big reasons that it's getting a lot of adoption inside Kubernetes is that they can take the very similar policies and apply them outside as well. So for that idea that I can have a policy engine that works on my virtual machines deployed in the cloud, my virtual machines deployed on prem. My container based workloads and bare metal workloads. And I can write one holistic idea in the same language to enforce all of my security policy and best practices. It's a really powerful thought and Styra are the people that had it and Styra is also the primary development team for OPPA. And then getting into like, how do I communicate with this community? All of the all of their source codes out on GitHub. So github.com slash open policy agent. There is a slack for open policy agent, which is I know I'm on and I'm pretty sure Rachel is too. We've got questions and we're bouncing ideas off of people all the time. So the slack is active and stuff is happening in there all the time and the development team is very active in the slack. And also a couple of Twitter handles for Styra and OPPA or OPPA as well for both of them to have. There's just good Twitter handles to follow and it's the Kubernetes world. So everything's a Twitter handle right. So looking at what is open policy agent and this is where we get into the bits and the bytes and all the geeky stuff. We've set the table with all the business logic and the use cases now we get down into into the good geek bits. So what is open policy agent? What does this thing do or how does it do it? So have to start with a definition and apologize for the eye chart. But it's also worth mentioning here and I'm not going to read the whole definition. But just pointing out that it's a general purpose policy engine and it's a high level declarative language and all those buzzwords that you need for anything that you're going to have. But the cloud native computing foundation, which is a pretty important thing in the Kubernetes ecosystem, this is an incubating project. So OPPA is part of the CNCF, which is very important because it helps make sure that the OPPA community has governance models wrapped around it and all that stuff. But it's also a general purpose policy engine. And like what we were talking about a minute ago, it lets me provide one set of policy rules for my entire infrastructure, regardless of where it's deployed, regardless of how it's deployed. And it's just a really, a really good thing. So this quote is coming directly off the CNCF website. So inside Kube, inside Kubernetes, OPPA gets deployed is what's called a validating admission controller. And well, there's a chart on the next slide, but what a validating admission controller happened does is when you type in Kube CTL create dash F and feed it some YAML. All of that hits the the Kubernetes API server. And when you have a validating admission controller configured when the Kubernetes when the API server gets that request, it takes the request and hands it off to the admission controller and says, can you please validate this is this using whatever your policy engine is, is this a valid request per your policy? And if the policy engine says yes, then the object gets created. And if the policy engine says no, there's something wrong with it. Well, then your deployment, your objects don't get created. And it gets logged as to why. So one of the really important ideas of where OPPA sits in the in the Kubernetes world. And we'll take a look at just what I just described in picture form. And this is straight off of the OPPA website is OPPA validates the objects to make sure that they're they're in compliance with whatever policies have been written before the object ever gets created. And that's a really important idea when you stop and think about it. I don't want to do a security scan after I've spun up something and brought it onto the network. And it sounds kind of common sense, but a lot of tooling does the scanning after the fact. This does the scanning. This does the validation before after the object has been requested, but before it gets created. And that's a very powerful, very important spot to live inside an application's lifecycle. Because I can that's these validating admission controllers are the last line of defense before an object gets created. They're also in a very good spot because I get to say I get to take all the information that you've added into this into this stuff. And I get to decide if it's okay or not. And that's what OPPA does. So the one thing it was on the previous slide, but I didn't have a chance to mention or I just didn't squeeze it into the to the word suit that I'm spewing out right now. Is all of those policies inside OPPA are written using a language that Styra has developed and is developed based on a bunch of stuff that's been around for a long time called Rigo. And Rachel is going to show us some examples of Rigo here in just a minute or two. And Rigo is that high level declarative language that we write all of our OPPA policies in. So you'll often hear when you start getting into OPPA and start writing your things, you'll hear OPPA and Rigo kind of used interchangeably. It's kind of like YAML and Kubernetes. You know, when you start talking about the YAML, what you're really talking about is the data that represents your infrastructure and how all of that glues itself together. So when we're talking about OPPA and Rigo, Rigo is the definition of all of our policies to make sure that everything that happens inside Kubernetes happens the way we plan on it happening. So Rigo is the language that OPPA policies are written in. And I think this is the last slide before we get to the live demo because we're all here to see a live demo because that's what everyone wants to see at conferences. There has been some pretty dramatic growth inside OPPA, the code base itself that is OPPA. And you'll see pretty different experiences depending on the version of OPPA that you use. And I think the demo that we're doing today, Rachel was kind of picking and choosing between the different ones. I think we're going to be using a version 1.0 demo that uses Kube management, the sidecar deployment to enforce all of the policies. And the reason we're using that one is because it is the most obvious. It's the fewest layers of abstraction between the policy and what's happening inside Kubernetes. So it's the easiest to visualize and it's the easiest to kind of learn on. And as you get into version two and then into version three, you get a more comprehensive tool set. You get a more sort of cloud native Kube centric deployment methodology, but you're abstracting, you start abstracting things away. Whereas in the version 1.0 stuff, I write a policy, I apply it as a Kubernetes config map to a pod and then it's done. So there aren't as many moving parts in version 1.0 as there are in two versions two and three. So what you often do when you're getting started with OPA, which kind of a nickel's worth of free advice, is you start with version 1.0 because it's the lowest barrier to entry. And then as you get used to writing the policies, then you start bringing on versions two or version three into your Kubernetes implementations, your Kube deployments to bring in those additional features and to have a little more efficient experience once you understand the basics. And it's the way what we see most customers doing. Just sort of how the OPA ecosystem works, at least in our experience. So that's all of the death by PowerPoint that we're going to throw at you. And I think we have about 10 or 15 minutes for the live demo and then a little time after that for the Q&A. I have to put one bad joke or one bad joke on all of my presentations and this is this one. So this is like the SpaceX demo two. So it's demo two, but close enough. So with this, I'm going to hand it back over to Rachel and she's going to turn three times and hope that the live demo works. Thanks, Jamie. Yeah, so as Jamie mentioned before, we want to get to the good stuff, the demo, but we also want to take a step back and look at some examples. These are all real world examples that we've used for customers. And also, you know, you just want to start, how do you get involved? Like I said, what's the barrier to entry to OPA, right? Just how do you get involved? How do you get started? So I want to also just show you very simply, we're not going to, for this demo, I'm not going to install OPA. This has already been pre-installed, but I want to focus on the logic and the sense of how you approach developing OPA policies. And how do you obviously build upon that once you've kind of got the foundation going? So let me share my screen. Give me one second here. And let's do this. Here we go. All right. So you should be able to see right now I have just the tutorial. This is the base tutorial to get anyone going, anyone started. It's very straightforward. And like I said, I'm not going to walk you through it. You can take your time and go through it. And as you can see, it deploys OPA onto the top of Kubernetes for you. So I've already done this. And, but I just want you to see, you know, it's very, it's there for you. It gets most of it done. You don't have to really think too much about it. And by the end of it, I always suggest, no matter if you're Kubernetes expert or OPA expert to just go through the demo here, right? And just make sure that OPA is actually running because sometimes it does have its little quirks that it doesn't run right away. So as you can see, the first policy that they give you is very, I would say it's actually very complex. It's a lot of lines here and it could be intimidating. So, and I've seen this a lot in a lot of the demos where they give you these long, complex examples and you're trying to sit there. Because you're trying to learn rego and OPA and sometimes Kubernetes as well. So you don't want to see all these lines of code when you're trying to learn a new, you know, technology or some new resource. So I want to show you what's the simple approach, how to, how it started with the customer. And then we'll go through how to actually test it. So this example I'm showing here is one, this example was because some actually one of our customers, one of their operators simply created a CRD and deleted a CRD. Just because they were new to Kubernetes as well. And most of the team, they're still learning, but they just made a simple mistake and it caused a lot of issues downstream for the customer. So the security team came to us and said, we got to figure a way how to prevent some of these things, right? But not completely block the user from doing it. But they just want to make sure that the user goes through the appropriate channels before they make these decisions. Because like I said, everybody's learning Kubernetes as well as OPA and any other security pieces that they had. So their first approach was like, literally just listing out what they think that the user should not be able to do right off the bat. That was completely as it was just one liners, right? And then this one here was like, you know what, we don't want a user to be able to create a CRD without going through the appropriate person. So I said, fine, let's see how we could approach this. We could probably use either we could have thought about, okay, let's use PSPs or OPA or any other technology that they want to use. And just so you know, they use PSPs and OPA interchangeably. It was whenever it was for the right use case. So we decided to do this with OPA. So as you can see here, this looks like the similar to the example we saw before, right? You got your basic rego here. You got your package statement. You got what you're going to be denying. And as you can see, it's three lines that are very effective. All it is is just you're looking here. You're saying, you know what, if I see a custom resource definition being created or try to update, we're going to block this person from doing it. And then you put a nice little message, right? Say, hey, you're in trouble. You know, don't do this. And then this is another way you can also give you a customizable approach to Apollo 2 security because a lot of times it might get blocked, but the user doesn't know why. So you could also fill out details to either contact someone or a department or reach out to a certain email, whatever it is, you can customize your messages here. So it's very straightforward. The next part of this is once you've kind of gotten your head wrapped around a little bit around rego, you want to do some testing. And you want to do some test coverage. So similar to if you're used to doing J unit testing, right? You want to do coverage of all the possible. Okay. So yes, we are doing conferences differently now. So I'm sorry about that or until some technical difficulties, but let me share my screen again. And then we will go back, take a little step back. Okay. Hopefully you can see my screen. You can hear me good still. I'll just go back to and here we go. So like I was saying before, you want to make sure that you're testing, you're doing a lot of coverage to meet all the possible scenarios for when you're working with open just like you would any other development process. So here is an example of a very simple test case where it's a mix between looks like a little bit of rego as well as YAML, right? It's mimicking what a manifest that would come through to the API server. So I'm not going to go into much depth here, but you can just see that it is referencing a CRD and the operation create. And at the end here, it's showing that it should be blocked by the by based off of this policy here. So let's go and test it. And that's the way I like to approach my development. It's, you know, once I've created the policy, you don't want to just go in and throw it into into your cluster because then sometimes it might block everything. It might block something else that you didn't expect it to write. So you want to test it locally first. So that's what we're going to do here. So I basically have a folder where I have here my my policy as well as the test policy. So we're going to OPA has a client, a command line client that you guys can download. And, you know, I said you can go to their site and do that as well. But basically very straightforward. You just do OPA test. There are some ways that you can look at more details about it, but you would just simply do OPA test. You have the name of the policy that you want to test and then what test file that you're testing against. So let's do that here. And I like to just name my test just because it helps me remember, you know, which one I'm testing against. And then very simply here, it shows you that it passed. We can also see if it failed, it just gives you a message of, you know, hey, this, this is failed. This particular one's failing. So for example, if we change this to zero, because it's saying what this policy is saying now is, hey, it's supposed to not deny. It's not going to deny. So it's supposed to fail that it should fail because we want it to deny. So we run it again. You should see here that it failed and you'll get an error message like this. It doesn't give you a lot of detail on why it doesn't give you the logic on why it failed. It's not something that you kind of have to go into, but it does tell you at least which test case failed. And if you have a lot of them, which I've done for customers where we have maybe a hundred test cases that we're going through for maybe about 10 policies, right? You test them all at once. You kind of, you want to see which one is particularly failing. Okay. So that's out of the way. You're all good. You've tested everything locally. You're feeling confident about your policy. So now you want to go play around with it in a cluster. I always suggest still have obviously wherever you do your testing on a dev cluster. One thing that you might want to do is inform others that you will be testing on this cluster. This has happened to me before where we loaded up a policy and one of the developers came in right after me and needed to actually perform the same action that I was testing against. So we ran into some issues that way. So just always makes me conscious of where you're testing your policy and informing others of when you're going to do this. So the first thing that we would do is right now, as you can see, I got a cluster up running here and it's got an opening space. I said this is all described in the, in the tutorial. So how to get all that set up. You'll see I got some opa pod here running in the open name space. So that's been running for a while there and very simple. We're going to wherever your file is located. So I said I have my policy here and you're going to create a config map. So of course, you can create a config map multiple ways via the file or let's call it CRDA block. That's the name of my config map. And so there's many ways you can do this. If you're testing in a block of you can load them all up at once, however you feel best of doing it. I'm going to load mine individually just because I like to test each policy individually just to really understand what's working. What's not working. And let's do, oops, hold on. Did I do the wrong? Where am I missing here? Hold on. There we go. That right go. Okay. So our CRDs are, sorry, config map is created. And let's look at the config maps. Opa also puts a config map here. I said that's all described in the instructions, but I also had another one here as well. And if you're obviously if you're running a lot of policies, you'll see tons of them in there. So let's take a look at the status of the config map just because you want to make sure that it's actually in there and that it's running. So you want to check a couple of things. So the first thing with this is the data. So this is, as you can see, it's your policy. It's the exact same thing that you wrote in a condensed form. And so this way you can read it. And then the most important thing is a status. So the config map obviously might come off, but if the status is as an error, you're going to obviously it's not going to work. So you always want to make sure that your status is okay once you create your config. So now we've got our config map in there. Opa is now kind of sitting looking to see if I try to create a custom resource. And let's see if it blocks it, right? Hope fingers crossed demo gods here. Let's go. So we're going to do a simple, you know, create a. We're going to just do this one here. My manifest. So I'm going to create my manifest here in my and you'll see that fingers crossed. It should block it exactly. So as you can see, it gives you the same error message that I use to to block what I wrote, you know, customize it. And that's pretty straightforward, right? So if you go through that, I can delete, I'm going to delete the same config map. And I'm going to try to apply it as well. Give me one second. So we're going to go back and apply it. And now it should go through. So there you go. Very simple, very straightforward demo. It's very effective for customers. And basically, as you can see here, it blocked it, didn't doesn't block it. And what I suggest is, you know, kind of take this and you build upon it. So, you know, if you wanted to go into more details and more depth on how to how it works for your customer or your environment, then you can build upon it starts small and then increase on the foundation of of it. So that was just really quick demo there and we'll basically get back to the slide. So let me stop sharing my screen here. Sorry about that in true conference call fashion. I was talking on mute. So kind of bringing this in for landing, bringing it back to value and why OPA is important to what you're doing is the Kubernetes security best practices have to include admission controllers. You have to have that last check to confirm that what your what your developers and what your operators are telling Kubernetes to do is in line with the policies of what should happen. And OPA is the community leader in that world. So OPA is is a vibrant community that's growing. The adoption rate is growing around Kubernetes. And it's going to be around in five years. So that question of is it going to happen is there getting started isn't hard. What Rachel showed you is a valid use case. I mean, that wasn't a hello world kind of demo getting started with OPA. The lift is not very high. It's a little weird feeling when you have that feeling of, oh, I'm going to do a default. I have to deny a deny is a good thing in the world of OPA. But again, when you realize that it's coming from the security background that it is, then it makes a little more sense. And it does take a little bit of getting used to. But the lift to get there is not bad. And then a few links that we wanted to post in there to give you Rachel's back. Rachel, you know, walk through the links real quick. So the links that are just straight, the OPA documents. One other thing is a nice link to a blog that Jamie also wrote enhancing, you know, goes into more depth. So enhancing Kubernetes security with OPA, just more in depth of what we showed today, more details on how to expand upon this demo. Another thing is gatekeeper, right? Version three, right? How do you take from version one and go to version three? And then also the next cool thing is a nice cool podcast. I love the K files, which are very own. Jamie Duncan has gotten and created this nice podcast on various IT solutions and in areas. But he has a great episode on OPA where he goes into more depth with other of our colleagues in the industry on how to leverage OPA for yourself and your customer. A couple of shameless plugs there to wrap everything up. And with that, we're about, looks like we have maybe 10 minutes for Q&A in the live Q&A section. And we just wanted to say thanks, a quick shout out to VMware, the VMware open source team that's helping, you know, helping bring all of this stuff to life and helping bring this into customers. They have a great blog series. The link is on the bottom of this last slide. And thanks for the time. All right, great. Well, I just spent 30 minutes listening to my own recorded voice and well, I survived for the first time ever. So we've got quite a few questions in the Q&A. I think I'll distribute in Rachel. Like I said, during the, during the talk, Rachel is the brains of the operation. But I think I'll, I think we agreed I'll MC them. The first one is what is the use case when roles and role bindings don't work and we need to move to OPA. Rachel, is that, is that essentially what the demo was? I'm not in this case. We didn't, in my experience, we didn't focus too much on that. That is an area that I am researching myself because it is coming up with a lot of our customers. So I will be doing more in depth on that. So I don't have a definite answer for you, but I do suggest go to the OPA Slack workspace and check that out there. And someone will have an answer there. If not, then I don't know where else you can go, but that's the place to be. Yeah. And I think the rule of thumb is that it's not an either or situation that you could all of these, all of those tools that I talked about at the beginning of the session are part of your security stance inside Kubernetes, including OPA. And like anything in Linux, Kubernetes gives you 17 ways to shoot yourself in the foot, which is great until you have 12 holes in your foot and five things left to try. You could probably write really complex RBAC rules to get most of the functionality in OPA. And you could probably write really complex OPA policies to get most of the functionality of the RBAC engine inside Kubernetes. But with the goal of keeping things as simple as is practical, there are things that RBAC lends itself lends itself towards. And that's, I have a user that can do a thing in a project or cluster wide, very straightforward. A user can create a pod, a user can create a service, a user can create a load bound, you know, can create a top level Kubernetes object. But there are times when those top level objects have different purposes. And that's when OPA comes in. So maybe you want to be able to create certain pods with certain annotations or not. That's where OPA starts again, that more fine grain control of those top level objects. And then when you get into custom controller objects, you know, you have to start extending RBAC and doing all sorts of crazy stuff. So they're really just kind of look at what you're trying to do in the words of the mortal Duffy Cooley. You know, what problem are you trying to solve and then use the best tool for it. Sometimes that's going to be RBAC, sometimes it's going to be OPA as or some other validating and mission controller. And just go with what's going to give you the most straightforward answer. See the next one. Hey, Jamie, there was just a follow up to that. When should I switch to OPA and do not use roll bindings in? Like Jamie said, this is not either or, right? It's kind of more of a conjunction. It's a partnership. There are scenarios when you would just use OPA to do something and when you'll just use roll bindings and a combination of both. So it's not a, it's not a get rid of roll bindings or it's completely moved to one or the other. Yeah, completely. Use the best, you know, everything's not a nail. You know, use the best tool that use the best tool. Someone also noted that the policy looks a lot like roll dot YAML. Well, in particular, when you're using the, in the example that Rachel gave, we're using essentially the policies written in a config map and the config map is YAML. When you start using tools like gatekeeper, you know, it's still going to be YAML, but it's going to be a little more abstracted out. It's going to be a little less coob, coob native. It's going to look a little less like the Kubernetes contracts we're all used to. But yeah, it totally does because it's a config map and it all kind of looks the same after you stare at it long enough. See our pod security policies strictly weaker than OPA or other things OPA can do but cannot do, but PSPs can. I'll take that one Jamie as well. This is another one that comes up quite often. So there was a conversation about PSPs going away. They're not going away in replace of OPA, right? You can be in this customer actually that I showed in the example, they use both, right? There was times when they needed, they could just do what a PSP kind of kept it a little bit simpler, right? And then they would use OPA for everything else, as well as OPA can be used not just in Kubernetes, right? It could be used for Docker or, you know, other, other IT solution. So it's not just Kubernetes focus. So it's not either or I personally worked more with OPA than PSPs. I found that it was a little more robust, but that could have just been my experience. So yeah. Yeah, I think it's just a little more fine grained. But I wouldn't say weaker better. Again, I think it's just sort of apples and oranges or at least different kinds of apples. Someone's making jokes about me being a history major. Let's see. What's a what's the use case when roles and role bindings don't work and we need to move to OPA? Rachel, you want to jump on that one or you want me to? I'll let you take this one, Jamie. I had to think about this one. So again, it's that idea of having very fine grained control. So you can set up a role, you know, a role binding. You can set up a role to in a project that says, you know, this service account or this authenticated user can create cannot can create a pod or cannot create a pod can create a load balancer cannot create a load balancer. And that's fine. But when you get into different kinds of pods, you know, like if you have a namespace that have your that has your database deployed to it, you don't want to deploy things that aren't in your database. And or also if you want to deploy a pod, great, I can deploy a pod and I can set roles and role bindings to let me create or not create different objects inside Kubernetes. But I can't create a role binding list. I don't know how to create a role or a role that will let me only create burstable pods that will not let best effort pods be deployed. But you can very easily write an OPA policy that says all all deployments, all deployment objects, all pods have to have requests and limits as part of their definition, and that it won't let it deploy if you don't. And that while into in product in dev that's not all together that important sometimes but in a production environment, you know, your best effort pods are the first ones to be, you know, out of memory killed. So you want to make sure those, you know, your production stuff is the is the last stuff to get to be affected by in a resource contention issue. So there are, again, it's just about that granularity roles are back I can I can or cannot do a thing to a Kubernetes object with OPA I can interrogate those objects based on their annotations based on their labels, based on other anything that I can inquire about in the definition of the object and build policies off of that interrogation. So I can just get way more fine grained when I'm using OPA. And that said, roles and role bindings are very important because I need to paint with broad strokes before I paint with the small brushes. Hopefully the paint analogy makes sense. See, looks like the last C to do. Do you think OPA might increase cold start time for Kubernetes serverless frameworks. I've never tried, like I've not used like I've not deployed OPA on like in like a K native environment. Probably some. But it's just something you're going to have to test out because there are so many variables there that are going to get into what your application doing, what's the startup time, all of that fun stuff. I wish I had a good answer there follow up with me on Twitter and maybe we can dig into that one a little more, but I think we're just about out of time here. And, and thanks a lot for coming to hang out. All right, thank you everyone and like to follow up with us on Twitter and we'll get to your questions.