 Hello, everyone. Thank you for joining us on our talk, DevOps, all the things, creating a pipeline to validate your OPA policies. My name is Goran Nusam. I'm a senior lead technologist at Booz Allen Hamilton. I'm a big fan of Korgies, Raman, and occasionally when I have two Kubernetes with me today, I have. Hi, my name is Karthagam Balan. I'm also a senior lead technologist at Booz Allen Hamilton. I'm happy with spicy food. It's five movies anytime, and I love anything open source. Awesome. So today, we're going to be talking to you about open policy agent. Karman, could you please tell us a little bit about OPA for those viewers that might be new to the technology? Sure. OPA or open policy agent is an open source general purpose policy evaluation engine. It takes any JSON data as input and evaluates that against predefined policies or rules written in a declarative language called regal. The fashioning policies and code users are able to decouple policy decision making from policy enforcement. And OPA allows us to define rules that lay out how your system should behave across the stack. And this, of course, relates to the DevOps stack as well. Right. It's not enough to have these policies live in a vacuum, right? At its core, DevOps is about streamlining value to customers by shifting lift quality assurance, which includes security as much as possible. Continuous integration has become a standard that many teams adopt automatically by executing unit tests and integration tests as part of their DevOps pipeline. These same practices can and should be applied to infrastructure's code, configurations code, configuration management. And today, we're going to demonstrate how to apply these practices when developing your OPA policies to ensure that things work as expected early and often. Carpagam, could you tell us a little bit about some of the tools that we'll be using in our demo to address these stages? So yes. There are many tools that wrap around the OPA engine to provide policy enforcement capabilities at various layers of the stack and various stages of the DevOps cycle. Along with some of the policies that we have written today in regal, we are using some such tools to help automate and strengthen our development and enforcement process. One such tool is the gatekeeper, which is a Kubernetes admissions controller. When gatekeepers install in the cluster, the Kubernetes API server will trigger the gatekeeper admissions webhook to process the admissions request whenever a resource in the cluster is created. And based on the results of this evaluation made by the gatekeeper's OPA engine, the admission of the resource to the API server will be either granted or denied. Another tool we will use is called CONF test, which is also a wrapper around the OPA evaluation engine. CONF test allows us to statically run validation tests against policies that we have written before we even actually go install those applications and deploy them. This allows us to verify that the policies we are writing are evaluating as we expect them to. And of course, the manifest we are developing are complying with those policies. Another tool we'll be using today in our demo is called CONSTRADE. That's K-O-N-S-T-R-A-I-N-T. An open source contribution by an organization called PLEX that translates generic rego policies into specific templates used by gatekeeper that are called constrained templates and constraints. This allows us to keep our policies as generic rego core and have different tools evaluated and enforce the same set of policies at different points in the DevOps cycle. Finally, we will use gate pre-commit hooks to automate using CONF test and constraint together to automatically validate the manifest the developers are creating. This process allows us to ensure that all code that we check into our application reports is conformant to our OPA policies. Gaurana, I think it's time for a demo. I think you're right. Okay. Let me switch our view here. Okay. And just to set the stage a little bit, we do have a Kubernetes cluster that's running. And I think my port forward timed out, of course, demo gods. All right. We have, just to set the stage, we have a Kubernetes cluster that's running. I have Argo CD deployed into it with some applications that we're going to use to showcase here. We have gatekeeper already installed in the cluster. So it's already activated and ready to do its job. And I have a couple of empty applications here that are going to hold our constraints, right? So they're empty right now. Sorry, constraint templates as well as the constraints, which is where they're going to live. And we're going to see them get deployed. And then I also have like a little demo app of components that we're going to test against these constraints to see them launch successfully. So just to set the stage there. And so now if we go to the terminal, I have our little repository here and we'll start right with the policies directory, right? This is where we're centralizing all of the various rego policies that we're writing. So if I look into one of these here, I can see that we have the rego source actually in here, right? So this is, this is the rego code that we're using to write the various policies that we want to enforce in our cluster. So this is good, but this isn't, you know, to convert any spec, right? We need actually something to load this into our cluster. So that's where that tool that Carpagon was talking about comes into play, which is called constraint. Constraint does the job of taking generic rego policy files like this and creating constraint templates and constraint files for us, which we then can use to launch into our cluster and have OPA consume them, right? So just as an, just to dive a little deeper, constraint templates basically describe the, the rego that enforces the constraint and the schema of the constraint, and then the constraint itself is the, basically the definition of what we want to enforce and how, right? And so for that, we've actually written this little wrapper script around constraint and all this does, it does some cleanup if we try to run this multiple times, but it'll call constraint against the policies that we've written in our policies directory to generate the constraint templates and constraints and then it'll place them into two directories that I have our go CD watching to be able to deploy those files, right? So let's actually do that. Let's call this script now. All right. And so if I do a get status, I can actually see that we've created a bunch of files. We've created several constraint templates and we've created several constraints to go with them. So I can actually add those right now. And we'll commit and we can push those to our repository, right? And so our go CD seeing this commit now is going to pick those up, but just so we don't have to wait for the default Argo refresh to actually check our repository, I'm going to hard refresh it here to tell it, hey, we've got some changes since we're a little short on time. And so our go CD has already picked out the constraints that are coming up. It recognizes them from the source code that we've committed. And it'll start creating those custom resource definitions, which OPA gatekeeper will then consume, right? So the constraint templates are there. And there is a there's an order that needs to be done in place. The constraint templates have to be created before a constraint can be created. The constraints depend upon the template to know how to instantiate, right? So if I go back into my applications and I go into the constraints and this doesn't start slowing down. Demo God's why there we go. We'll do the same refresh. This is crazy. And like it's like it knows we're recording. All right. Sorry about that. Internet issues. What can you do? Anyway, so now we've seen that the constraints have launched, right? So these have now been loaded into gatekeeper and gatekeeper is actually ready to start enforcing these new policies that we've just loaded in using Argo CD. So going back to my little demo here, I actually have a directory that has some it has some files that will violate certain policies that we have running in our cluster. For example, we've made it so that containers that try to spin up images using the latest tag are nonconformant, right? You might wish to pin your applications that you're launching in the cluster on specific versions. You don't necessarily want to use the latest tag because that can contain breaking changes that you don't necessarily want to deal with until you go through a rigorous process of evaluating those changes with the newer versions. Additionally, we've decided to enforce resource limits, right? We don't want people to create deployments or containers that don't have resources specified. And finally, we want to be explicit about not running containers as roots, right? So you can see I've commented those out. But basically, if I try to create this deployment right now, it's going to fail for several reasons that I just covered. So let's validate that, right? Let's do acute control create dash F with container. And we can see here this is a response from gatekeeper saying, hey, your action is denied for all these reasons, right? Images must not use the latest tag. Container resource constraints must be specified. Pods can't run as root. So we can see that literally the policies that we just instantiated into our cluster are already being enforced. But what if I'm not someone that has acute control access? What if I'm just a developer that is trying to commit some code, run it through a pipeline, get it deployed into a cluster? I don't necessarily use acute control to get my resources into the cluster. I just make a commit, right? So I have that demo folder that's being watched by Argo to deploy applications. So what if I just took this container and I moved it up to the demo directory that's being watched by Argo, right? And let's add that. And let's try to commit it. Let's just do a commit. We can see here Conf test is basically validating what we're trying to commit in the demo directory against the policies that exist in our policies directory, right? So not only are we actively guarding against new objects being deployed into the cluster, but we're also guarding against, you know, the development phase of developers trying to push objects or code that's non-conformant, right? So this is just a local get commit hook, a pre-commit hook that basically tells us, hey, you're trying to commit something, but it's actually not conformant. So let's actually fix it, right? Let's go into the demo directory and into the container that we have in here. And hopefully if I've made it easy enough with some of these comments, we can easily change this. Let's see, 25. Let's change the latest tag and specify a specific version. Let's uncomment the resources that we want to implement here. And then let's bring in a security context and specify that we don't want to run as a specific user, right? Let's write that. Let's try to commit it. And let's see if the get... Oh, I messed up the spacing, of course. I believe I am one short here. Let's try again. Security context also needs to be moved one more. Thank you very much. There we go. Thank you. So now we can actually commit this. We can say adding, sorry, adding, right? And now we can actually push this. And if we push it, Argo should pick it up and we can go into our demo apps. My port forward failed again. My internet is just loving me tonight. Go into our demo apps, do a hard refresh. And we can see that Argo is going to start deploying that container since it's picked it up from source code. So that's great. So let's do one more test. I have one more file in here. In this directory, I have a namespace that we potentially want to create, right? So this namespace is going to check for a specific label, right? Let's say we have Istio running our environment. We want to make sure that Istio injection is enabled, right? So we'll do the same test here. We'll try to create it. And we should get back, hey, you can't do this. You need to have the proper label installed on your manifest, right? So same thing. Let's try moving it. See if we can be sneaky and get around this and try committing it. Same thing. Hey, your manifest isn't conformant. So we're going to not allow you to commit this. So let's fix it again. And let's refresh one more time. And there we go. The namespace that we have there is getting created, right? So that's good. Cool. Let's go back to our PowerPoint, right? So let's go over what we just covered, right? We've showcased how you can centralize all your rego policies. You can extrapolate this to your own organization in that this allows you to keep all your rego policies for all your various applications in one location in source control. This location can then be leveraged by any of your pipeline tools that require those policies. We've showcased a process that allows you to automate the creation of constraints and constraint templates, which are valid Kubernetes objects that Gatekeeper can consume, as well as the seamless deployment of those resources with Argo CD. We've shown you use cases that validate these policies that are deployed into the cluster by GitOps using Argo CD. And finally, we've shown validation in the development phase, right? Using Conf test and Git hooks to not only give validation feedback to application and manifest developers, but at the same time continuously validate the rego policies that exist in our code repository. So what's next? Well, the Git, the Git pre-commit hook that we showed is local, right? You can take the same validation test and make it a part of your pipeline so that the manifest and policies are validated before deployment. Policies can be developed independently, centralized in one location, and can be enforced uniformly across the DevOps lifecycle. You don't want to test new policies or changes to existing policies in a live environment. You could set up a pipeline that employs Terraform and validates with TerraTest to generate an ephemeral Kubernetes environment, apply your policies, and then run a battery of tests to validate against those policies. When those tests come back, you can improve the merging of new policies to your code base. And that's it. Thank you so much for attending our talk, and we'll be around to take your questions in the chat. Thanks. Bye.