 Hello, thank you for joining us for this Open Policy Agent Intercession. My name is Ash Narkar. I am a software engineer at Styra, and I'm one of the maintainers of the Open Policy Agent. I care about developing software that can be readily deployed, scaled, managed, and is secured by default. In today's presentation, we will look at OPAS Community, talk about the Open Policy Agent, check out its roadmap, and then get some updates from subprojects like Gatekeeper and Conf Test. So let's get started. The OPAS project was started in 2016 at Styra, and the goal of the project has been to unify policy enforcement across the stack. One of the earliest adopters of OPAS was Netflix, and they've been using OPAS for authorization over their HTTP and GRPC APIs. And companies like Chef Pinterest into a Capital One and many more have been using OPAS in production for use cases such as admission control, RBAC, ABAC, data protection, and so on. OPAS is a CNCF graduated project. It has more than 100 contributors on GitHub. It has a healthy Slack community of more than 3,000 members. It's been starred more than 4,500 times on GitHub and is integrated with more than 20 of the most famous open source projects out there, some of which we'll see later on. So what is the Open Policy Agent? OPAS is an open source general purpose policy engine. When you use OPAS, you are decoupling the policy decision making from the policy enforcement. So your services can now offload policy decisions to OPAS by executing a query. So let's understand this a little more using this figure. Imagine you have a service, and this can be any service at all. It can be your own custom service. It can be on UI, STO, a Kubernetes API server, any service at all. So whenever your service gets a request, it's going to ask OPAS for a policy decision by executing a query. OPAS will use the policy and the data it has access to to evaluate this particular query. And then it will return a decision back to your service where it gets enforced. So you can see that we have decoupled the policy decision making and the policy enforcement. The policy query itself can be any JSON value. So for example, if you're doing HTTP API authorization, this policy query could contain the request path, the method, the user, and so on. The policy decision itself can also be any JSON value. And then it's up to your service how to interpret that decision. Now let's look at some of OPAS features. At the core of OPAS is a high-level declarative language called as rego. And with rego, you can write policy decisions that are more than Boolean allowed tonight through false. Your policy decisions can be arrays or objects or collection of values. OPAS written in go. And it's designed to be as lightweight as possible. So all the policies and all the data OPAS needs for evaluation are stored in memory. You can think of OPAS as a host local cache for your policy decisions. You can deploy OPAS as a sidecar, as a host-level daemon. You can embed it inside your go code as a library. And now you can even compile your rego policies into awesome executables and use them to evaluate different inputs and data. OPAS does not have any runtime dependencies, meaning it does not have to reach an external service or it does not need to talk to any external service to make a policy decision. You can extend OPAS to do that, but that's completely optional. OPAS does provide you with some management APIs that allow you to fetch policy and data from an external service. OPAS can upload its decision logs to an external service. And OPAS can also upload its status to an external service. All of this information can be used for offline auditing purposes. And finally, along with the core policy engine, OPAS provides you with a rich set of tooling that allows you to build, test, and debug your policies. OPAS provides you with a unit test framework so that you can unit test your policies before you actually deploy them. OPAS integrated with IDEs like WIM, IntelliJ, VS Code. And there's also an online interactive tool called the Rego Playground, which you can use to experiment with Rego policies and share your Rego policies. So these are some of OPAS features, a high-level declarative language, multiple deployment models, management APIs for control and visibility, and a rich tooling set. If you look at the cloud-native landscape, there are new projects that get added every single day. It may be a new database or new service mesh or a new gateway. And so if you are building a system comprising of the projects you're seeing on the screen, you're going to have a lot of moving parts. And if you think about security, especially authorization, you can imagine each of these projects are written in different programming languages. They have their own way of controlling access. And so what eventually happens is that you have no visibility into the security posture of your system. So what would have been really helpful if there was a way to unify policy enforcement across this diverse set of projects? And this is one of the motivations behind the creation of OPAS. Like I mentioned before, it's a general-purpose policy engine. It's not tied to any particular data format. As long as you give OPAS some kind of structured data and you write policies that make sense for that data, OPAS will return a decision back to you. And that's why it's a general-purpose policy engine. So the projects you're seeing on the screen right now, this is just a subset of the integrations OPAS currently supports. And the cool thing here is that you can take any of these integrations out of the box. And without having to write a single line of code, start using OPAS today to enforce custom security policies in your cluster. So if you all go to the OPAS website, you'll see an integration page, an ecosystem page. There we've documented some of these integrations. So if you all want to get involved with OPAS, you want to contribute to OPAS, one of the best ways is to write up an integration with your favorite project and open policy agent. And then you all can have it featured on the OPAS website. So we highly recommend you all do that. And we hope to see a lot of integrations in the future. So now let's look at OPAS roadmap. So we released this roadmap that highlights some of the work that is being done by the OPAS community this year. So one of the things we'd like to do is to update the docs to provide examples of the bundle, status, and decision logging management APIs to enrich the user experience. Optimizing support for wasm-compiled policies is something that is actively being worked on right now. And there's also work going around improving the static type checking by extending the OPAS eval command to accept a JSON schema file for the input document in order to get precise errors while you authorize policies and thereby improving your developer experience and productivity with OPAS. And so this is just a snapshot of the work that's been done by the OPAS community. This roadmap is publicly available on GitHub and we encourage you all to check it out. And so now let's get some updates from subprojects starting with ConfTest. So ConfTest is a utility that helps you write tests against structured configuration data. ConfTest became part of the OPAS family last year. And we'd like to share the latest from the project. ConfTest provides a plugin feature that allows you to extend the CLI without having to change the ConfTest codebase. And so now ConfTest supports the XTG specification for its plugins. You can find the official Docker images for ConfTest on Docker Hub at open policy agent slash ConfTest. And lastly, sometimes while writing policies over configuration files, you may want to know the folders where these files are located and you want to probably use them inside your policy. So for example, you may want to check that the folder named by the config file as present matches the game space of the resource, for example. And so the folks at ConfTest are working on this new feature, which will be out soon. So this was a summary of all things ConfTest. And now I'm going to hand it over to Orin for all things Gatekeeper. Thanks, Ash. Hi, I'm Orin Shamran. I'm an engineer at VMware and one of the maintainers on the Gatekeeper project. My focus is to help make Kubernetes more manageable at scale. So what is Gatekeeper? Gatekeeper is an extensible admission controller for defining and enforcing policies over Kubernetes. It leverages OPA under the hood for making policy decisions while providing a Kubernetes native layer on which operators can define their policies once and reuse them across multiple contexts. Quick history of the project. Back in 2017, Styro released Kube Management, a sidecar for loading OPA policies from config maps. In 2018, Microsoft released Kubernetes policy controller and donated it to OPA. Later that year, Microsoft, Google and Styro and others began collaborating to reimagine policy management, the fruits of which became the Gatekeeper project. This diagram visualizes how an API request flows through the system. Kubernetes provides hooks for mutating and validating a request prior to admitting it into the cluster. Gatekeeper integrates OPA and rego into the flow to help make these policy decisions. Let's talk about some of the core features of Gatekeeper. Gatekeeper allows us to write policies as declarative configuration, which can be parameterized to encourage reuse. It supports audit, which periodically evaluates resources against constraints to track compliance across time. And with dry run, you can gradually roll out new policies without breaking existing workloads. Finally, with context awareness, you can define referential policies that enforce uniqueness of a field across constraints. The Gatekeeper API is built on top of the constraint framework. The constraint framework defines Kubernetes-based abstractions over policy in the form of constraint templates and constraints. A constraint template is a custom resource describing a parameterized rego policy to be enforced by OPA. A constraint is an instantiation of a policy which binds it to a particular context using matchers, as well as providing arguments to customize behavior. A new feature we've been working on for the past few months is mutation. Mutation allows us to modify a request prior to applying it to the cluster. This opens up new opportunities to establish secure defaults, inject sidecars, and tag resources with acquired metadata. Let's talk about some of what's new with Gatekeeper since the last KubeCon. We've introduced alpha support for mutation, and new Gatekeeper operators under development, which will provide an alternative for installation and lifecycle management. We've added support for user-facing warnings on Kubernetes 1.19 and above. We've improved documentation, reduced memory consumption, made cache warming improvements, refactored our constraint library, and much, much more. And now let's see a demo of what Gatekeeper can do. Okay, we've talked in the past about how Gatekeeper can be used to enforce security policies. Let's look at another example of how it can be used to implement reliability standards for your cluster. Here we have a constraint template which validates certain probes that are defined on a workload prior to being admitted. A readiness probe will prevent Kubernetes from routing traffic to a service before it's ready to be processed. Here we have an example workload which has omitted the readiness probe. Let's see what happens when we try to apply it to the cluster. First we'll load our policies into Gatekeeper. Now we apply the workload. As expected, Gatekeeper has rejected the workload as it lacks the required readiness probe. Here we have a second properly configured workload. This time it adheres to our policy and Gatekeeper admits it. Now let's see the new warning support on Kubernetes clusters 1.19 and above. Warning is a new enforcement action similar to dry run. The main difference is that it's able to give immediate user feedback while still admitting the resource. We'll test this with a policy which requires an owner label set to warning. Now when we apply a resource which violates the policy we'll get a warning but the resource is still admitted. Finally, let's look at some of what's possible with the new alpha mutation support. We'll use a single pod and show how it can be modified by multiple mutations. Allow privilege escalation as the security context field which can have surprising results if it's not set explicitly. This mutation will ensure it always has an explicit value and will default to false. Next, we'll show how to set missing image pull policies to always. Using assigned metadata mutations we can tag our resources with metadata such as an environment label. Finally, we'll show how to use mutations to inject the sidecar into workloads to augment functionality. Let's load all these mutations into Gatekeeper. Again, here's our original workload. Let's apply it to the cluster and see what happens. First, we can see the image pull policy was applied. Next, a security context was added with the allow privilege escalation set to false. Scrolling down, here's our sidecar that was injected. And finally, we can see the environment label that was introduced into the metadata. So what's next for the project? We're gonna be working hard to bring mutation to stable and can't wait to get your feedback on the new functionality. We also have a proposal on how Gatekeeper could be integrated with external data providers to allow leveraging large datasets in our policy decisions. Finally, we'll continue to refine our tooling metrics and constraint library. Thank you so much for joining today. You can learn more about OPA, Conf test and Gatekeeper on the web. We have a Slack channel where you can ask questions and we're on GitHub. Enjoy the rest of KubeCon.