 Hello. Thank you for joining us for this talk on decoupled policy to enable architectural choice. My name is Ashnarkar. 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 ready to deploy, scale, manage, and secure by default. In today's talk, we'll look at the policy enforcement problem. We'll see what it is. We'll see how OPPA can help us resolve this policy enforcement problem. We'll learn a bit about OPPA, its features, and use cases. So let's get started. If you think about the cloud native landscape, there are new projects that are being added every single day. It may be a new service mesh or a new gateway or a new CI CD project, a new database, and so on. And so if you're building a system which comprises of all these projects, there are going to be a lot of moving paths in your system. If you think about security, specifically authorization, you can imagine a scenario where each of these projects is written in a different programming language. Each have their own way of controlling access, which may be tightly coupled to the underlying system. And what ends up is you have no visibility into the security posture of your diverse system. Even from a flexibility point of view, if tomorrow, say you wanted to swap out the service mesh, you now have to spend time and money to recreate those same policies to conform to your new platform. And you might say, we'll just use dogs and wikis to enforce policies until you have tens or even hundreds of these services and that wiki approach is no longer sustainable. And so what we need is a way to enforce policy across all these diverse systems in a highly performant manner. And this was one of the reasons for creating the open policy agent. We learn more about the open policy agent in the next few slides. So what is OPA? OPA is an open source general purpose policy engine. When you use OPA, you are decoupling the policy enforcement from the policy decision making so your services can now offload policy decisions to OPA by executing upgrading. We'll understand this concept a little more, but before that, let's look at OPA's community. OPA was started in 2016 at STARA and the goal of the project has been to unify policy enforcement across the stack. One of the earliest adopters of OPA was Netflix, and they've been using OPA for authorization over their GRPC and HTTP APIs, as well as companies like Pinterest, Intuit, Capital One, Yelp and many, many more use OPA in production today for use cases such as admission control, RBAC, ABAC, risk management, data filtering and so on. OPA is a graduated project at the CNCF with more than 150 contributors on Git. It has a healthy Slack community of more than 4,000 Slack members. It's been starred more than 5,000 times on GitHub and it's integrated with more than 20 of the most famous open source projects out there, some of which we'll see later on. Now going back to what OPA actually is and how it works. So imagine you have a service and this can be any service at all. It can be your own custom service, it can be Kafka, it can be Kubernetes, absolutely any service at all. So whenever your service gets a request, it's going to ask OPA for a policy decision by executing a query. OPA is going to evaluate this query based on the policies and the data it has access to and send a decision back to your service where it gets enforced. So you can see that we have decoupled the policy decision making from the policy enforcement. The policy query itself can be any JSON value. So if you're doing Kubernetes Admission Control, this policy query can be your pod manifest for example. If you're doing HTTP authorization, the policy query can contain your request path, your method, the user and so on. The policy decision itself can also be any JSON value and then it's up to your service to interpret that decision. Now let's look at some of OPA's features. And the core of OPA is a high-level declarative language called as WEGO. And with WEGO, you can write policies which are more than allow deny through false yes, no. You can write policies that return sets or objects or strings or collection of values. For example, OPA can help you answer the question, can Bob access a particular field? And OPA can also help you answer questions like which fields can Bob access? OPA is written in GO and it's designed to be as lightweight as possible so all the policies and the data it needs for evaluation are stored in memory. You can deploy OPA as a sidecar, a host-level daemon, or you can embed it inside your GO code. And now we can also compile REGO policies to Wazel and use those executables to evaluate your queries. Think of OPA as a host local cache for your policy decisions. OPA does not have any runtime dependencies, meaning it does not have to reach any external service to make a policy decision. You can extend OPA to do that, but that's completely optional. OPA does provide you with some management APIs that allow you to upload policy and data to an external service using its bundle feature. It also allows you to upload its decision logs to an external service. So for example, every decision that OPA makes, it's logged and you can take these logs and upload them to an external service for any kind of offline debugging. OPA will also upload its status to an external service, its health to an external service as well. Finally, along with the core policy engine, OPA provides a rich set of tooling that allows you to build, test, and debug your policies. That is our unit test framework. There are integrations with IDEs like WIM, VS Core IntelliJ, which allows you to author your policies. The unit test framework allows you to test your policies before you actually go and deploy them. And there's also the Rego Playground, which allows you to author policies and share those policies with the entire work. So these were some of OPA's features, a high-level declarative language, multiple deployment models, management APIs for control invisibility, and a rich tooling set. So we saw this figure before and we said that OPA can act as a unifying authorization engine across all these diverse projects. And the reason for that is OPA is not tied to any particular data format. As long as you give OPA some kind of structured data and you write policies that make sense for that data, OPA will give you a decision back to you. And hence, it's a general purpose policy engine. The cool thing about this is that you can take any of these integrations out of the box. And without having to write even a single line of code, you can start enforcing custom policies using OPA inside your systems. And this is just a snapshot of all the integrations OPA has. There are more on the OPA website on the Ecosystems page. If you'd like to contribute to OPA, one of the best ways is to take your project and integrate OPA with it and have it featured on the OPA website. So now let's look at some of the use cases starting with Kubernetes Admission Control. Those of you all who are not familiar with Admission Control, it's basically a piece of code that intercepts requests to your Kubernetes API server before that request is persisted into HCD. So Admission Control is an excellent way to enhance the security profile of your Kubernetes cluster. So with OPA as an Admission Controller, you can enforce policies which are shown here on the page. Some of the policies are shown on this page. So for example, if you don't want to pull images out of any external registry, you can enforce a policy around that using OPA. Or if you want your containers to specify CPU and memory limits, you can do that with OPA as well. Or if you don't want your container to run in the privileged mode, you can achieve that with OPA. In fact, all of the port security policies, you can implement them using the Open Policy Agent. So the way Admission Control works is that whenever you do something, whenever you do like a poop cuttle create some port, that request is going to be sent to OPA. And the input that OPA gets is this deeply nested structure that you see on the left, which indicates the port manifest, which is the Admission Review Object. And now OPA has to use this deeply nested structure as input and based on the policies and data it has access to, evaluate this input and send a decision back to the webhook. And the decision that OPA sends in this case, which is the Admission Response, you can see it's not a simple Boolean. It's sending the result as well as why that result was made. So now your webhook can have more information to provide to the user why OPA made a particular decision. And again, you can see that we have decoupled the policy decision making, which is done by OPA and the enforcement, which is done by the webhook. And so in this way, you can use OPA as an Admission Controller to enhance the security profile of your Kubernetes cluster. Next, let's look at another use case around API authorization. We know that a lot of organizations today are moving towards a microservice oriented model because it does provide a lot of benefits. But microservices alone do not solve age or distributed system problems like authentication, authorization, service discovery, and so on. In fact, these problems become even more acute because of the heterogeneous and the effemeral nature of microservices. In fact, Netflix was one of the leaders in microservices has publicly spoken about how difficult it is to get authorization correct at scale in a highly performant manner. And so imagine if you have like tens, hundreds of thousands of microservices and each microservice is making a decision on each of those thousands of API calls per second on whether they should be allowed or not. That's a really difficult problem to solve. And so what we need here is a solution that is highly performed, which fosters collaboration. So for example, each of these microservices may be written by different teams, each authoring their own policies that it would be great if there was a way to share these policies across teams and reuse some of the policies. So we need a solution that encourages or motivates such collaboration. And finally, we want the solution that allows us to write fine grained security policies. So I hope at this point it's it's pretty clear that what the solution is, it's going to be the open policy agent. And so like I mentioned before that you can integrate open in multiple ways like Zagore library, or a host level demon or a sidecar. We'll see in this example, how we should integrate open with a network proxy. And the advantage of this method is that your application stays as is you don't even touch your application, and still you can enforce custom security policies for API authorization. So the way this works is that you have on voice so for those of you are not familiar with on what it's a layer seven proxy and communication bus designed for large service oriented architectures. So imagine you have a Kubernetes pod inside your pod are going to have two containers one is the on my container and one is your application container. So the way this works is whenever there's a request for your application is intercepted by on what which forwards it to your application. The application is going to return a response back to on what which returns it to the end user. And now inject opa this flow by using a mechanism called the external authorization filter with sends a request to open. Now this request contains all the context open needs to make an informed choice about the fate of this particular incoming request. So opa is going to evaluate this request based on the policy and data has access to send a decision back to on why and if open denies a decision on what sends a photo three to the client. If open allows the decision, then like before the decision goes to your application gets a response and then on why forwards it to the end user. And see again in this example we have decoupled the policy decision making, which is done by opa from the policy enforcement, which is done by on what, and we haven't even touched the application. And still we are able to write very fine grade security policies in this example for HTTP API authorization. So now, when you think about authorizing your microservices in a highly performant manner, I hope to think about the open policy agent. So this was a talk on decoupled policy to enable architectural choice. You can check out more about opa and learn more about opa at open policy agent of park. You can join us on slack. If you have any questions or use cases you want to discuss and check out the project on GitHub, and please do start the project if you like what you see. So again, thank you for joining us and sharing your time with us today. Thank you.