 Hey, can folks hear me? Great, great. I've been back and forth between Hangouts and Zoom all morning and sometimes the audio gets lost. So if you haven't sort of checked in in the docs, please add yourself to the docs. Looking for two individuals really did not do a good job at sort of capturing notes last session and apologize for that. So looking forward for two volunteers to focus on minutes, capturing some minutes, especially as we're getting these use cases, I want to make sure we capture the questions and answers since those will be sort of key things that will help us build our case. Turner, are you presenting? Who's presenting on your side? Yeah, I've got the slides. Cool. You want to test your slides out while we're waiting for folks to log on? Sure. Yeah. Hey Dan, I think a couple of us are having issues accessing the doc. Hmm. All right, let me give everybody the request for access. I think I've got every, should have open editing while we're alive. Oh, I don't even have permission to view it. Yeah, me neither. Okay. No, no, no, it's there. There is an issue that it was closed to the group. Anybody in the domain had it. Sorry about that. You should have access now. So for everyone's logging on, you know, I've got in the chat, the meeting notes. Please add yourself. Great. Great. Thank you. Appreciate that. Um, could I get, uh, someone else to, to help support Torn? One more volunteer. We'll get started. I can, I can help take notes. But, uh, I don't have. Okay. Access. Yeah. I'm going to, you know, I'm going through and adding everybody in this sort of cumbersome, uh, cool docs process of adding people. All right. So continuing today with, with our use cases, uh, we have, uh, the OPA, uh, use case that we're going to dive into, uh, thanks again to, just free for sharing the, um, the cloud. Um, that was a great discussion and, uh, you know, really insightful to, uh, uh, you know, get that context. And, you know, we had a number of folks who, who've had the opportunity to, uh, collaborate with the OPA. And, uh, so we wanted to take, uh, the full session today to, uh, you know, talk about the, uh, the OPA use case that we're going to dive into. Uh, thanks again to, just free for sharing the, um, the OPA to, uh, you know, go through the use cases and, uh, you know, hear a bit about, uh, of the journey that, uh, the team, uh, you know, behind OPA has been, uh, uh, going through and, uh, uh, you'll go through some, some questions and answers today. So, uh, um, forget who's got Tim. Is that, that you has the slides up? Sorry. Yep. All right. So Tim, uh, go ahead and take it away. Okay. Thanks. So, um, so what I thought I'd do is spend a few minutes just giving you a quick overview of OPA and sort of setting the stage there and then, and then talking just a little bit about, uh, the process, the journey as you say that we've gone through and then, and then diving into the use cases on, obviously that's the meat of the discussion, but I thought we should set the stage a bit first. Um, and so, uh, and so, uh, the first thing that, that I think the, is to mention is just sort of the goal of OPA, right? The goal of OPA has always been to make it easy to add rich policy support, um, to other projects and services, right? That's been the goal. I think of OPA is sort of like a library in that sense. Um, but, but the idea is really that you've got like, as this picture shows, uh, what we expect to have, have happened is that OPA is running in, in a bunch of different places. Um, and you know, those OPAs are integrated with different kinds of systems, like maybe in the, in the microservice case, you've integrated OPA with all the different microservices that are running. Uh, or maybe you're integrating OPA into different components of Kubernetes or into Linux or into, uh, all kinds of different places. And we'll go into what some of those use cases are and what, what people have found OPA useful for. Um, but then the idea is that we want to make OPA really easy to, to use and take sort of zero runtime dependencies. It's always been one of the goals to make it very easy to integrate, very easy to deploy. Um, and then the idea behind OPA is that it's really intended to be something that can make policy decisions for something running right next to it, right? So we like to think of this as like a host local kind of Damon that knows how to make authorization or more generally policy decisions for anything that's running on that host. But the goal of OPA is never to, has never been to be a service. It's never, uh, it's always just designed to be basically a library or something that answers, answers questions from, from services that are sitting on the host. And so the sort of, uh, the sort of management of how you integrate and, and deal with multiple opus has always been an, an out of scope for OPA. And so I think, you know, from my understanding of what safe is, is designing to do, um, this, this seems like a natural fit for, for, for safe. Um, all right. So I think that was the goal. Um, I will, I'll skip to some of this. Uh, everybody here knows, uh, roughly what the policy problem is I'm assuming. And so one of the things that OPA does provide is a declarative language. It was designed to work fundamentally with JSON data. We'll see some examples and use cases there. I already went through this. It's a library Damon. It's all written in go. So if you want to integrate as a library, you've got to use, you've got to have your system, your, your service written in go. Um, all, all storage of, of data and policy, all of that is done in memory. Right. And so, and so having a management piece that is, is capable of actually feeding OPA, uh, those policies and any data it needs is, is valuable there. Now we've done a bunch of work around, uh, tooling as well. So OPA has, you know, a, a, a, a, an environment where you can go into and run, uh, and ask for the results of evaluating ad hoc queries or, or just running the policy even without having deployed it. There's a test framework for writing unit tests. There's tracing to do debuggability. Uh, and then we're working on some profiling stuff to look at performance. Um, we are working on a standard library as well. So that you don't have to write policies from scratch. You go and you pull them in and, and immediately you're up and running. Um, uh, without even necessarily having to write policy. Uh, and then what we're going to do is for the most part, focus on a bunch of these integrations today. Um, any questions so far? Sounds good. All right. I'll keep, I'll keep hammering away. Okay. So, um, consensually the way that the, that OPA works is that remember the goal of OPA is to add policy support to an existing project or service. And so here we have a sort of a pictorial representation of that. So we have some service. It doesn't matter what it is. Maybe it's a microservice. Maybe it's Kubernetes. Maybe it's, uh, CASCA. And then what you do is you, uh, there's an API that OPA exposes so that that service can ask for, uh, policy decisions for, for enforcement decisions. So the idea is that the service anytime it needs an authorization decision, it just, it opens up a simple HTTP request and asks OPA for that decision. Independently, there's a management API that's used for OPA. And through that API, you actually provide OPA with two different conceptual pieces of information. One is logic. This is sort of like the policy that you would expect, right? Allow this user to run this API call under these conditions. That's kind of the logic. We use rego. That's the language for expressing that logic. And then in addition, though, you can, you can provide OPA with arbitrary JSON data. And so typically what this data represents is something that's happening in the world. So in the Kubernetes case, this might be all the, all the pods that exist. Or in the, in the microservice case, maybe the data is, you know, something like your org chart so that, you know, who's a manager of whom. All right. And so these are the two kinds of APIs that OPA exposes. The, the, in particular, they're both sort of initiated by, by things outside of OPA. So today the service is the thing that initiates the request. It says, OPA, tell me what a decision is. And likewise on the management side, there's some external management system that needs to actually push that logic and that data into OPA. And so what we end up doing, at least for some of the integrations, for some of the use cases that we've done, is that we've added a service-specific management sidecar to OPA. So for example, with Kubernetes, what we've done is there's a, there's a sidecard that runs next to OPA that, that goes and pulls policies out of the Kubernetes API server and pushes them into OPA. And likewise, that Kube sidecar will go off and grab, let's say, all of the pods that are currently running the API server and push that as data into, into OPA. And so that's sort of the, you know, the division that we saw earlier, which is that OPA is really intended to be this post-local policy engine that makes decisions that's completely separate from the management piece. All right, questions about that? I have a question. You mentioned that you pulled the policies out of the Kubernetes API server. Are those the RBAC policies? So do you essentially have an enforcement for RBAC policies in OPA? Not today, not today. We could. Certainly we, and in fact, Toren did the, did translation of, he had a collection of RBAC policies and showed how you could write them in OPA. We didn't automate that. It's all in Toren said. But, but yeah, we definitely talked about adding that kind of functionality where you could take an existing policy language and then sort of compile it down into, into OPAs. But what the, but what we did do, or what, what exists is called the CUBE management, it's in the CUBE management repo within the Open Policy Agent GitHub org. What that actually does is it, is it pulls OPA policies out of a config map inside of Kubernetes and then pushes them into OPA. So the way that you sort of use OPA for at least a Kubernetes, for at least a couple of Kubernetes use cases is that you write your policy and you push it in as config maps. Ah, okay. Okay. Thanks. Yep. Anything else? Okay. So I mentioned the APIs in the last slide. And so I figured, especially given some of the interests of this group, it was worth spending a couple of minutes just talking about what, what APIs OPA supports today to give you a better feel for this. So really there are two kinds of APIs that OPA supports. Here on the top four are really the management API that I spoke about. And then there's really one, at least, there's one main one for doing, for doing enforcement, right? So on the end four, well, I guess I should start with the management. The really, in the management API, there's really just crud on policies. That's the first two lines. And then there's crud on data, right? So remember for us, we've got these two things that come in the policies and the data. And so really there's just, you know, sort of standard management APIs for, for dealing with both the management data, getting them in and out and updating them within OPA. So those are the first four APIs. And then the fifth API is really the one that asks for, for a policy decision, right? And here the idea is just basically open up a GET request. And so all that the service needs to do is run a GET request on basically a URL that names the policy that they want the decision from, okay? And so it's really pretty much that simple in terms of the API. The one thing I'll mention here that, that's noteworthy in this sort of REST API space is that all of the policies and all of the data are registered at human readable path names. So like when you create a policy, you can create it at foo slash bar slash baz in the API. And then that's reflected in the policy language as well. The same is true of data. You can register data at whatever, whatever path you like. And then decisions are also named via paths. So you could ask for a decision which is like, you know, a policy decision slash, slash microservice slash app A. And then you get the decisions that are for the policy that's registered at that point. Any questions there? The only other thing I would throw in is just that like those policy decisions when you get them, you can provide arbitrary JSON input when you ask those decisions. So like you can represent, you know, the API request that you want to authorize or whatever is JSON. You just pass that in the body of the post request. Yeah. And it turns out that the, I mean, I can't remember if I mentioned the term domain agnostic here, but in the, in the intro to OPA. But, but the idea behind OPA is that it should work for any kind of domain that we like. And in order to make that happen, sort of the, what ends up working is that when you pass a, when you make a, when a service makes a decision, a request for a decision from OPA, the input that it provides can be any arbitrary JSON document. And that's how OPA achieves this domain agnosticity. If that's a word. The idea being that because you can pass in any arbitrary input, that input could represent the microservice API call, such as method path and user, or it could represent a request to do SSH, which is here's the host ID and the user, or it could represent a Terraform plan. And we'll see examples of all these things shortly. Does OPA support approaches for validating data. So for example, if I'm passing a jot, can you, can you, can you do validation on that? Yeah, so. So yeah, typically the way that we think about it is that we do trust the input that comes in. We assume that there's some sort of trusted tunnel between the service and OPA. But specifically with respect to Jots, I'll mention that we have been asked a couple of times to add enough functionality inside of OPA to actually do that kind of validation in the policy itself. And then the policy language itself today already has enough control to be able to like inspect the internals of a jot token to make policy decisions using the information contained within that token. How are the OPA APIs itself for the policy that's decision secured? Like how do you authenticate the service itself which is calling into the OPA decision API? So today we have bare tokens, if you want to do that. Typically what we, you know, or at least often what we do is we just, we just sort of assume that there's a trusted tunnel there. But yeah, bare tokens are what it's just doing. Yeah. There's a lot of features OPA is running locally on the host next to, next to the service that it calls the OPA. So we assume that like local is secure. You can run OPA, the OPA server with TLS enable. If you wanted, like you need to encrypt the traffic. Like Tim said, you can configure OPA with bare tokens for authentication. And then obviously OPA would not be complete if you couldn't write authorization policy over the OPA APIs themselves. So you can do that as well. So you have, you know, support TLS authentication and authorization on OPA itself. And then some people have been asking about support for like mutual TLS authentication when talking to OPA. And so that's sort of on the roadmap. Thank you. Okay. So yeah, it felt like it was this kind of topic. It was worth spending one minute talking about the journey that we're taking to get here and where we are. And so, you know, we started OPA roughly two years ago in 2016 and we spent basically the first year building the basic OPA, the language, the API and so on and so forth. Last year we spent basically the whole year investigating how to use OPA to solve other people's real world problems, right, and building the community around OPA and getting it out and then taking what we'd learned by running through numerous use cases to sort of help climb the language and the implementation and the API. And now this year really our focus is on like hardening. So we're looking at building a B2 of the language with, you know, some of the folks that I know were, I saw on one of the docs, Sarah and Tristan out of Google. So they're very interested in working with us on the B2 of the language. And then we're also looking at, so trying to improve the ease of use of the language, make it a little bit more programmer friendly, looking at performance, and then of course continuing to solve real world problems, right, in building communities. So what we thought we would do for the rest of the talk is just go through some of the use cases that we've used OPA to solve from a number of different places. All right. So here's our picture of the classes of different use cases that we've solved with OPA. And so we're going to go through, I think, most of these. I'll just highlight them, you know. So really remember OPA is designed to be domain agnostic, which means you can apply it at really any level of your proverbial stack, right? So we've applied OPA sort of at the orchestration layer here with Kubernetes, at the individual sort of host layer to do like Docker and Linux control. We've done integrations with OPA, the sort of public cloud layer with Terraform to do some risk management. We've solved use cases with OPA at the microservice API layer as well. That's been pretty public around, we've been probably most public around that with Netflix and Istio. And then recently we started getting into, or not us necessarily, but users have started using OPA to do some data protection stuff in this sort of Kafka open SDS and Minio space. All right. So I'm just going to go through some of these and the ones and try to, what I tried to do is sort of just, we can't go through all 20 or however many integrations, but go through sort of the key categories of integrations that we've done and use cases that we've seen. The interesting thing, I did spend some time for this meeting trying to think through some of the different dimensions that we think about when we're looking at a new use case. And so we thought that this would be valuable for this group just because it does sort of highlight some of the different things that you need to think about when you're thinking about a use case, at least in our experience as a case. So I'll just run through these one at a time and then very quickly, but then what I'd like to understand is from this group's position, which of these things are most interesting to you? And then I can sort of highlight those as we talk to you in the different use cases. So the first one is just sort of basic policy, like what kind of policy were you even writing? And obviously this is really interesting from an OPPA point of view, because OPPA is fundamentally a language. And so understanding what kinds of policy and what kinds of expressiveness requirements are needed is an important property of any use case. The second thing is data and context. And this is typically from OPPA's point of view, data represents what's going on in the world. And so sometimes they're going to make policy decisions. You need information that the requester does not provide. For example, in the microservice API case, if you want to authorize an API request, you may need to know whether the user that's making that request is a manager in the organization, right? And that management information is not always something that comes in as part of the request. So what data and context you need to actually make decisions is valuable. The third thing here is what do the decisions look like? Classically with authorization policies, the decision is always true, false. It's loud and I. Maybe there are a couple others like not applicable, but fundamentally they're often allowed and I. And one of the things that we built into OPPA from very early days was the ability to make decisions that were not just allow and deny statements. You can return decisions that are numbers. For example, you want to do rate limiting or strings or sets or even dictionaries. And there are use cases throughout that will show each of those. The next thing is integration. In some sense, you're always at the mercy of the system you're trying to integrate with when it comes to actually doing the integration. So how does that even work? And that's something that we look at for each and every use case. And it's always a little bit different. Policy management is the obvious thing that we mentioned earlier, which is that every use case, at least for OPPA, requires potentially a different kind of management system. And then there's performance. It turns out that use cases can vary widely in terms of performance. We've got some use cases where, you know, spending 10 seconds to make a policy decision is fine. Others where you have to come in at under, you know, a millisecond if you're gonna make a decision. And then finally is a terribly named here, unfortunately, mode. But here the idea is that there are different ways of actually enforcing policy. One is the sort of obvious one, which is that we call it proactive here, which is that you stop policy violations before they happen, right? For example, you don't deploy, you don't allow a pod to be deployed on Kubernetes unless the policy says it's okay to deploy. But there's this other version, which is what we're calling reactive, which is that you look at the state of the world and you say, here are violations of policy. Now I'm gonna go off and fix them, right? And now this is actually more common than you would think. Like imagine in Kubernetes, you actually change your policy and now you've got a bunch of pods that violated that policy. Do you wanna go off and fix them or do you not, right? The third kind of thing here is audit. So here the idea is, well, let's go off and actually just identify violations and then use them and then plug into some external system to actually let people know that they're actually violations in place. Other questions or comments here? Oh, right, and let me know which things are most important to you. No opinions? How like when you're in that decommissioning state of pods, how easy it is, is it to leave those things behind? That's been a pain point. I haven't experienced that in Kubernetes, but in sort of other orchestration systems, having decommissioned nodes in there that have the wrong policy was one of those things where you're pulling your hair out, you're pulling your hair out, and it's, oh my God, we thought those nodes were gone and they're still there doing the wrong things. Yeah, well, I think one of our goals with OPA has always been this idea that you ought to be able to write a single policy and then apply it in any of these different modes, or at least to the extent that you can make that happen. And so at least with CUBE, the nice thing is that once you sort of get, just sort of pull all the data about the current state of the world, whether it's pods or nodes or whatever, into OPA, as we've already articulated, then the language itself was sort of designed around the notion of a query language. And so you can just ask the question, well, like tell me which pods and nodes exist that shouldn't, right? And then you can even set up watches that stream the results of that query back out to you. So I need to push that into a dash. So I guess I don't know how to answer your question, except to answer it with the way OPA would, the way we would use OPA to help with that kind of problem. Cool. Okay, well, I guess as we go, sorry, go ahead. A reasonable answer. So yeah, I just wanted, this is Sarah from Google. And one of the things that I think is exciting about OPA from my perspective is the ability to compose policy that might be from disparate services that need to work together. We need to reason about them together. But part of the safe working group is to zoom out a bit and say, well, we have a whole system that might be using OPA in one place and something else in another. And how do we reason about the overall system architecture and policies writ large? And so I'm curious about, you know, what your thought of, you know, if we're in a situation where like everybody in the world isn't going to use OPA, what are the things that we as a working group might need to define that would help OPA live within an ecosystem that is heterogeneous? Yeah, I mean, obviously the, you know, the standards things would help here, right? Like, so like having a fairly simple and standard way to ask for decisions, I guess, would help. I mean, it would definitely help the, so maybe I'll answer this from the user's point of view, which is that as a user, I'd like to have a consistent way of managing and dealing with all these different kinds of policy systems. What I'd really like though is to be able to reason about how the different policies, presumably in different languages, would interact with each other. And it's not clear to me what you can do there from an outside, like if we treat all policy languages as block boxes, and it's not clear to me what you can do there other than to have, other than to maybe surface actual policy decisions in some sort of format that, you know, some tooling to come along later and sort of combine them. Well, I think one of the things that, like sort of I have a hypothesis that, you know, like generally we're all kind of dealing with the same nouns and verbs for the most part, certainly the same nouns, right? So there might be some certain amount of where we say, okay, if you're deploying an app, right, or microservice, and you're in this world of deploying software that interoperates with other software via, you know, GSBIB, there's some set of concerns that you have, and if we were to standardize like words for those concerns or APIs to query, you know, or something, then you could imagine people being able to compare equivalent policies, right? Obviously if some policy system has capabilities that another policy system doesn't, that's one thing, but what I hear from people who have these heterogeneous infrastructure environments is they're, you know, they want to do something as simple as like, I want to know that, you know, these, these, these endpoints aren't open to the world, and I can't even, I have to write different code for each system to even ask very simple questions. And, you know, and I don't know whether that's, you know, what form that takes, but I think that we have this dream of like you say, like having tools that would be able to say, okay, I can go across all of these systems and without writing something that is custom for every system that I work with, I know that if it conforms to the, to the safe guidelines, right, that then my, this tool will be interoperable in some way. Yeah, and what I wondered, I mean, we've talked about this in the past, which is that it would be nice, it would be wonderful if there were some ontology, some schema that everyone in the world agreed on and that like represented all, let's see, let me go back, represented all the nouns in the, you know, in this landscape that we see here. And I think what, I've been hesitant to try to go down that road just because it seems, it feels to me like a, like such a gigantic undertaking and that will never be finished. And so what I think I would wonder about is how do we scope what you're talking about just to something where it's like, it's doable, it's, and yet valuable at the same time. And so, like, I think maybe the right thing to do is to do that from a use case perspective and, you know, tackle one use case at a time and once we're happy with that, then go on to the next. And it's not clear to me what else can be done there when it comes to, you know, standardizing the nouns at, you know, across systems as widely disparate as the ones that we use every day. Yeah, I mean, I think there's models for that out there in the world, you know, like how do we get to really standard mime types for email, right? Like there's processes that where we've done this on the internet before where we start with a few and there's ways to promote something to be what everybody uses. And that could be an exercise for the working group. It's painful consensus, but that's what we're here for. But I think what we're hearing is that even a few common things would be high value to the people using these systems, right? Because a lot of the auditing requires either some kind of manual inspection or custom code too. And then that's always worrisome and fragile. Yes. I'm focusing on the IBM team. We're sharing how in OpenStack, this was just left to vendors and, you know, the incompatibility was incredibly cumbersome. So, you know, it's, you know, an opportunity. All right. This seems good. Maybe I should hammer on and actually talk about some use cases. What do we think? Okay. So, all right. So, okay. The first one we're going to talk about here is CUBE. And I'll just kind of rattle on through some of this stuff and then stop me with questions. I'll try to remember to ask, but if I don't just jump in. Okay. So Kubernetes, we've done actually a number. We've seen actually a number of different use cases actually within Kubernetes itself because there are a number of different places that are extensible enough to support a policy system. And so, you know, at one point we have, we have an integration with the federation control plane. So here the problem, the policy problem is really given a new workload tell OPPA decides which, which Kubernetes clusters to place that workload on. Right. So that's the use case. There are others at the API server level around authorization and admission control. Here the idea is somebody is trying to create a new pod. And now OPPA needs to decide either whether to allow it in or not. Or we've used OPPA to actually define the mutations that need to happen to that pod before it's, before it's let through. And then in the, in the scheduler, we did a, we did an integration there as well to actually use policy to control effectively which, to filter out which nodes are not, are not used during scheduling. Okay. So we've got more details on these. The one that we get, we have more details on right here in the slide deck is admission control. So here the idea is you've got this, this pod effectively that we're trying to, to, to create there on the right hand side. And then the way that that works is that there's a web hook that runs inside the API server. And the, the nice thing is here that it's a generic web hook. And so, you know, we didn't actually have to go in and convince Kubernetes to talk to OPPA. We could just set up OPPA as a, as a web hook. And then, so then I guess the examples here that we're showing are that some of the policies that people like are, we'll make sure that labels exist, like every pod has a contact email address, control the number of replicas based on the type of application, the type of pod that we're deploying, make sure that there's certain metadata in place for the template. The other one that we've heard several times is let's use, let's make sure that all the images in this pod come from a trusted repository, like if we're, if this is a production cluster. So those are just some of the, the use cases that we've seen there. Oh, here, I think maybe I'll skip through this. I don't think people here are going to care too much about the language. I will mention though that, that the, let me see. The, yeah, here, the, that the input that comes into OPPA, what it makes a decision is this gigantic YAML thing shown here on the left, right? It is the full pod definition. And for the people who, who know Kubernetes Arbok, this is what, in some sense, what differentiates OPPA from Arbok, is that when you make policy decisions, you get to make them given the entire pod that's trying, that somebody's trying to create. All right. And then as I mentioned here, the decision in this case could just be true or false. It's, it's, it's a louder, it's not, but it could also be sort of a JSON dictionary that defines what amounts to a JSON patch for updates that must be applied to this pod before it's, before it's admitted. Questions there? Okay. Here, following on this interest in use cases, here are a few other example policies that we've heard people use in the, in the Kubernetes admission control space. I'm not going to, I'll just let you all sort of scan through those quickly. And we can post the slides to this online after meeting and then throw them into the notes. People want to go. That'd be great. Yeah, I'll follow up and send that out to everybody. Yeah. All right. Okay. I just checked the time. We've got about 20 minutes left. I will skip reading through these things. I'll just pick out a couple of highlights. In terms of management, we've already discussed how OPPA handles management within Kubernetes, right? We have the sidecar that pulls policies out of config maps and pushes Kubernetes data into OPPA. We actually have looked at this for both the proactive, reactive, as well as audit perspectives. I think we covered the rest of this here. All right. So let's go on. All right. So another use case and this, this we've seen quite a bit of interest in. This is sort of microservice API authorization. So the idea here, the problem that we're solving is that you've got a whole collection of microservices that are doing what they do and now we need to add authorization on top of it. The idea being here that each and every API call that a microservice sees is something that it sends to OPPA to ask for an authorization decision on, right? And so conceptually the way that you should think about this is that OPPA is running on the same host as every microservice. And so the nice thing then is that you get high performance and high availability, right? You're not paying a network hop to go hit some external service to get an authorization decision. And now the idea is that you're using OPPA to make those decisions on every API call. There are different ways of integrating OPPA with those microservices. Some, right, from top to bottom some folks will actually just do a direct integration with OPPA or what we just released I think this week was a spring integration where even the developer doesn't even know that OPPA is being used but the Java framework is actually taking every API call and authorizing it with OPPA. Some folks will actually embed OPPA as a library into the microservice. That's the second one. The third one from the top is effectively the service mesh version where you run next to your microservice a sidecar which is a network proxy that handles all the network traffic. And then what we do is an integration with that proxy so that that proxy actually asks OPPA for authorization decisions on every API call. There's another version in the STO world where OPPA was integrated into Mixer and so it can do centralized decisions there as well. And then the last one here I think we're just illustrating the fact that if you've got multiple microservices running on a single host they can all use the same OPPA. And so then here the interesting bit for this use case is here are the inputs that come in. As I mentioned earlier you can provide a path and a method and a source and a target and a user and then the policy that you write makes a decision about whether or not that API call is authorized. Questions here? Looking at this sort of the dimensions of comparison that we talked about earlier the performance on this one is critical right? So if you're the number that Netflix came out with was actually twice this. So 2,000 requests per second is what you need and then at least for them. And so like obviously the and I guess I didn't mention this previously but in Kubernetes the number was more like a second right or a tenth of a second something like that. And so obviously the performance demands in this use case are significantly different. But and so consequently there we ended up adding some functionality to OPPA to handle these really mission critical performance critical applications. And so that was just something that we needed to do. The other thing that we see is that for these kinds of use cases where performance is critical it also turns out that the amount of data that they typically use is smaller and the policies are written are typically much simpler as well. These decisions are basically allowing deny to false the classic authorization decisions. And we've seen people either do these integrations with a go library running it as a as a daemon or the other integrations that we talk about with the service meshes. So this question I see that you have a translation into there. So what's the reason for that? What is the other language? Oh yeah, yeah, right. So this was interesting. So this has come up several times in the last couple months where people want to use OPPA for this particular use case. So what they want to do is sort of split off think of this as maybe a service graph like so they've got some YAML file that represents a service graph and what they want to do is basically treat that as the actual policy. And so then what happens is that you end up writing a little bit of rego. Rego is the internal OPPA language. So you end up writing a little bit of rego to actually define the semantics of that YAML data. And then when OPPA is making the decision it will sort of combine that YAML data which defines let's say the service graph along with the rego that defines its semantics in order to make a decision. Now to translate it into rego just meaning that one of the features that we added recently to OPPA will take the data and the YAML and the rego and compile them down into pure rego and written in a simple form that we can evaluate very quickly. So that's the idea there that in this use case it seems like people want to have a sort of a secondary front end to writing policy which amounts to YAML or sort of a GUI and then what they want to do is make that very easy for users or application developers to write and then at the same time they want to use OPPA to actually do the enforcement. Yeah we can we'll also maybe post a link to the I've added a link to the bottom that partially YAML feature that Tim's sending out and I think that some of the idea here is like the developers want to provide like RBAC configuration basically to the system but the platform engineer and security team building the security platform wants to use OPPA to do all those RBAC policies and so that's something that's like well supported today and we're sort of continuing to the part in an optimized one. When it comes to management in this case Netflix ended up rolling their own their own management layer. They you know Netflix is good at replicating state and policy is an example of that so they rolled their own and I know is I don't know if Manish is on the call or not. I saw his name on the folks in the working group but they rolled their own. The other thing that we've seen in this is using for Istio using Kubernetes CRD custom resource definitions to store policy as well as data that's something that I think we're that may be coming out as part of Istio in the near future and then the other thing that we've seen in terms of management is we've seen several requests for sort of back-ends that will have OPPA go out and like pull policy out of Postgres or S3 or something like that and so like the management there is goes beyond what OPPA does for sure but it's a fairly simple kind of sidecar management system. Alright we'll keep on moving then. Another use case that was interesting here is in sort of public cloud space and this one is really focused on Terraform and using Terraform to manage the public cloud resources. So there were actually kind of two use cases that came out here so what happened was that there were really two cases right so one of which is you've got an application developer or a platform engineer who wants to make a change public cloud infrastructure so they go into Terraform, they make some changes to the file and then and then they want to go ahead and apply those changes and so what it was Medalia so what Medalia wanted to do was take the plan that Terraform produces and compute a risk score for that plan and then decide whether or not that user is authorized to make that change all by himself without peer review based on the risk score of the plan as well as based on how senior an employee they work right so if you're a senior platform engineer then your risk score might be like a thousand and you can make any change up to that risk score but if you're a junior developer maybe you're only authorized to automatically execute risk scores under 100 or something and here the risk score that they came up with was based on the networking ports that you open the number of servers that you deleted and so on and so forth so this is we did convince them to add this risk score policy to our standard library so I thought that would be good the second kind of use case is sort of the back end of that which is once you've already used Terraform to push and manage your public cloud resources how do you know that people are only using Terraform to actually manage that infrastructure and here the idea was what Medallia did was they took the AWS they took the state of AWS all the resources in it and then they took the Terraform state file which represents what resources Terraform knows is under its management you toss both of those into OPA and then you write policy that looks for differences right it's a show me a resource in the public cloud that is not also in the Terraform state and so they're using that for audit questions about those use cases right maybe to ground that I do have an example here of the kind of input that would come in that would actually ask in this case a risk score for this particular Terraform plan and so there was no way I don't know if any of you have seen Terraform plans but there's no way I could actually put on a slide so there's a whole bunch of ellipses here but you get the basic idea that there is pretty much an arbitrary JSON document that tell you all the different properties that are being changed and then you've got to write some sort of policy logic that decides how risky that changes here and here the decision here is a number it's a you know some sort of risk score oh and here I broke down the sort of two Terraform use cases in terms of these dimensions of comparison that we talked about performance here was not a real issue you know it's some person using it for the most part so it's not a big deal and then obviously here though the policies were quite sophisticated in terms of the kinds of inputs they required and in terms of the expressiveness you needed to actually compute a risk score decision was a number we talked about that we don't really have good visibility into how they're doing policy management in either of these cases but what seems sort of clear is that there aren't a thousand OPAs that they're using there you know one or two or ten so management is probably not all that okay we did all that great any other questions about the Terraform use case okay moving on then this is actually a recent category and we don't have as much data here but recently folks have been starting to use OPA to do data protection here we've got a couple of examples OPA and SDS Minio is new and Kafka is new so all of those so and in fact there's so I don't have a ton to say here other than what I try to do is again talk through the how each of these use cases correspond to those early dimensions that we talked about oh and there's another one here rate limiting that I didn't have on the graphic this is also new so for the rate limiting use case the idea is that somebody wants to set up policies to control network rate limits and so we're still not quite sure exactly what they're doing there but what we do expect is that the performance is pretty high again this is sort of close to the microservice API case and again they're doing this thing that Toran talked about and I guess I mentioned it too where they have a GUI or a YAML file for writing the sort of the core the crux of the policy that people care about and then they're effectively treating that as data when they author policy and in Rago here obviously the decision's a number and the policy management we know is going to be custom data protection is pretty similar here I don't think there's anything new again performance is going to be key decisions are typically allowed in I as far as we can tell in this case I have a basic question I mean we are going through like a lot of use cases there are different resources outlined there does OPA have like a specific schema for how resources are identified and you know like basically defined and you know like how attributes are set for those resources or is it like very open it's like a JSON data file that gets uploaded and then you know like write a policy on that yep yep it's the latter so we do not impose a schema on anyone and you know as I sort of mentioned earlier I wouldn't know how to begin that right so what we did instead is what you mentioned second which is the input that you provide to OPA is any arbitrary JSON document and then in the policy language you know what that schema is going to be when you're writing policy and then you express the logic that makes whatever decision you need it to make there in the in the policy language so there's sort of basically a contract between the the person who is setting up enforcement and doing that integration and the person writing policy so that once the the integration for enforcement is done then you know the schema that you're writing policy over and how does the user identity itself come into the policy decision making like so you can write policies where in you know like you have example policies wherein you have a user for which that policy is applicable but in a real like use case like how does the user context flow into the policy like typical example like how did Netflix do it or in the Kubernetes example so yeah the standard way for is to use something like a JOT right so I mean that's sort of an obvious way of doing this right so you have the user authenticate through a JOT and then you pass that JOT into OPA OPA does have support special support for JOT so that you can go and inspect the internals and yeah and then we've had a couple of requests to actually be able to validate tokens within the policy but in those cases we haven't sort of made a same sort of question as the first which is we don't require any sort of authentication scheme it's pretty open-ended right now so you can pass in tokens as part of the input here right just imagine there's another field in this input document that's like called token and so in that sense we sort of assume that the user has solved authentication in some way shape or form and that they have a trusted decision from OPA and so they can provide that user and however they however they like and then again when you're writing policy you know how that user is is being represented so so like in the case of spring for example like they they have a whole way of represented user like details basically right and so we just take that that object we just like send it into OPA as JSON right you get you know whether or not like the account is locked or like whatever the attributes are they define on like the sub or on the principle right but they already have a schema for that so we don't you know force that to change in any way we just let that get loaded into OPA's data and then you write policy over it so there's no coupling between OPA and these these like the way projects choose to represent their information right and the thing I'll add to that is that you know one of the you sort of want both of these things right with what you really like is to have a canonical way of writing policy over you but what you'd also like is to make integration super simple so that you can turn out a whole bunch of these things and so the question is how do you achieve both right because if you couple OPA as as as said and then to the actual enforcement point well then you got to change OPA for every enforcement point that doesn't work very well so we've done the opposite which is they well we're not going to require any sort of schema for users or resources and OPA will accept any sort of any sort of JSON data as input but then in the in the policy language the idea is that it's expressive enough to be able to to codify schemas or ontologies or whatever you want to call them so that you can still author policy at this sort of with this sort of canonical nouns canonical user formats or whatever and then you just write a little bit of policy that connects whatever format that data comes in as whether it's users or researchers or whatever into that canonical schema so what we do is we sort of try to to to get people to best of both worlds make the integrations especially simple but also give people the option of writing a sort of canonical policies and so what's what's sort of missing there is sort of a standard library that says well for a spring for a spring integration then here's how you map the spring user data into this canonical data format and for Kubernetes integration here's how you map the Kubernetes user information into that same canonical format now we support that we support that kind of logic but it's just not in the standard library today thank you I have a question do you only use the data and the policies as input to the decision or can OPA call out to other services as well for example to do job validation if you write that by hand you would have to be able to call and then certificates to validate right so the right picture in your head is that there's the input that comes in which is shown here there's the data that you can load from any data source from any kind of system on the planet and then there's the policy of course and then all of that is local to the decision and then fairly recently we added the capability to within policy go and make an HTTP call to an external system here the idea is the use case here is really one where you can't for whatever reason load that data into OPA and so what you decide is that I'm going to take an external I'm going to take a dependency on some external service and you know the consequences of that from a performance and availability perspective I'm willing to take that that availability and performance hit because there's just no other practical way to get the data I need in to make a policy decision so for example if you had a gigantic database it was a terabyte large well you're not going to load that into OPA and if what you know is that on every policy I only need to make a single you know I only need to check if a single row exists in that database well then you can use that external connector to go out during policy evaluation and check if that row exists and then another thing have you ever looked into obligations allowing you to manipulate the data that gives you some interesting policy yeah yeah for sure yeah so yeah we've been as I mentioned earlier we're working closely with Tristan and Sarah and they're all they know all about obligations and advice yes exactly so yeah exactly and so the plan is for in OPA today you can express those kinds of concepts because the policy decisions can be these arbitrary JSON documents they can you can include well here's the advice and here are the obligations and so from the caller's point of view you can return those kind of information there's no first door support though inside of OPA to do that that's not like a thing that OPA knows about but in some sense that's okay as long as you can express the obligations and advice that you care about because the burden is really on the client to actually do something with that advice and those obligations but like I said Sarah and Tristan are the experts here and we'll learn more as we go forward with them in v2 yeah I think that we're really excited about like that capability right and I think taking that layered approach makes a lot of sense like not putting like we don't need to put all of the concerns and how it's going to be used into the policy evaluation itself in fact it's stronger if we don't right let's only put the concepts into it that we really really need to because then it's powerful and can be used across many domains right right at least that's my current thinking exactly yeah we're on the same page for sure okay I do have some lessons learned I'm not going to throw them because we're out of time but I'll leave you with this Star is on GitHub and and and and participate on Slack that would be great so we'll try to post these slides yeah we'll put them on Slideshare and then put a link in the docs and answer questions feel free to hit us up yeah there's lots of people talking about political policy concerns on the Slack word so a lot of time that the conversation drips outside of just like enforcement API or you know enforcement data enforcement plane and it gets into the manager plane and and so we'd love to have on there that have experience you know with that that could contribute to the discussion so yeah but thanks a lot for the opportunity to present any final questions or comments thank you it was a wonderful presentation very informative thank you alright this was fun we should do it again anytime thanks Tim thanks to him really appreciate you guys helping us establish issues case alright thanks everybody see you next week