Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2018 (Copenhagen), 14 Nov 2015

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OPA: The Cloud Native Policy Engine - Torin Sandall, Styra (Intermediate Skill Level)

Description

Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).

OPA: The Cloud Native Policy Engine - Torin Sandall, Styra (Intermediate Skill Level)

How does your organization control;who can do: what across the stack? How do you enforce auth/z, admission control, and risk management policies in your micro-services, orchestrators, and CI/CD systems? How do you implement low-latency policy enforcement in the polyglot environments that your company depends on? In this talk we introduce the Open Policy Agent (OPA) project. OPA is an open source policy engine used by companies like Netflix and Medallia to enforce rules consistently, up and down the stack. We will showcase OPA features like hot-reload, tracing, and optimizations with demos of auth/z and admission control policies. Finally we will show how to integrate your services with OPA and provide examples of integrations for projects like Kubernetes, Istio, and more. Attendees can expect to walk away with fresh ideas about how to achieve fine-grained control throughout their systems.

About Torin
Torin Sandall is the technical lead of the open source Open Policy Agent project. Torin has spent his 10 years as a software engineer working on large-scale distributed systems projects. Torin has recently given talks on policy-related topics in Kubernetes at KubeCon, ContainerDaysPDX, Kubernetes meetups, and more. Prior to working on the Open Policy Agent project, Torin was a Senior Software Engineer at Cyan (acquired by Ciena) where he designed and developed core components of their SDN/NFV platform. Some examples of previous talks: How Netflix Is Solving Authorization At Scale (CloudNativeCon US 17): https://youtu.be/R6tUNpRpdnY?t=1041 Enforcing Bespoke Policies in Kubernetes with Admission Controllers (CloudNativeCon US 17): https://www.youtube.com/watch?v=llDI8VvkUj8 CNCF project proposal for OPA: https://github.com/cncf/toc/pull/71
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Okay, so this is a talk about the open policy agent project. My name is turin, I'm one of the cofounders of the project and one of the core contributors. I've also worked on policy related features in kubernetes and sto lately and I happen to love good restaurants. So this is a perfect city to come to to talk about policy.

A

So, for this talk, what I thought I would do is just jump in right away to some new technology that we've been working on and I'm really excited about this. This is the wiki I think that this represents the future of policy enforcement. As you can see, it's got this great high-level language that you can use to write policy on pretty much. Anybody can read and write this. It's super easy to update. It's got built-in contribution, guidelines and conflict resolution and I think that policy enforcement basically solved right.

A

So I'm, not I, haven't lost my mind, not being I'm, not I'm, not serious. I think this is a bad idea, don't do it, but at the same time I think that for a lot of a lot of us in our day-to-day lives when we're working with policy, this is like the best that we can do, because we've got so many things to worry about, and so we often fall back on things like wiki's and spreadsheets to keep track of the system and to manage the policies in the system.

A

Now what I want to talk about today is this idea of decoupling policy decisions from policy enforcement, because I think that this is actually a really good idea. So, if you take anything away from this talk, the idea that you should take away is that you should treat policy as a separate concern. So just like you think of the database and your message: brokers and your monitoring and your logging and all of those components as boxes in your architecture.

A

You should also think of policy as a box in your architecture, and, if you do that, what you're going to get, if you, if you decouple policy decisions from policy enforcement and you think of policy as a separate concern, you're going to get better control and visibility over permissions and policy and security throughout your system.

A

Now, when I think of policy I, think of like a set of rules that are supposed to govern how the system behaves and while that's a sufficiently general definition, it's not great because it's not very concrete, and so it's all very satisfying. But regardless of whether you have a clear idea of what policy is in your mind. Or you have a definition of it in your organization.

A

I would argue that many of you probably work with policy on a day to day basis because it actually affects all of us all the time so whether you're working at the application layer or with kubernetes or with host level infrastructure or cloud infrastructure.

A

Whether you care about things like how end-user data gets handled or you know where workloads are deployed or who can SSH into a machine or whether a config change is going to have a negative impact on the infrastructure, you all have to deal with policy all the time in your day to day lives, and so policy enforcement is actually this fundamental problem that we need to have good solutions for, because if we don't have a good solution for policy enforcement in the organization, then we're gonna risk massive fines. Security breaches, outages downtime, you name it.

A

So it's something that we have to solve, but at the same time, like I, said before we often fall back to things like wiki's and spreadsheets. So there's this term called tribal knowledge, which basically means like know-how or the collective wisdom of the organization, and so a lot of times. We rely just on tribal knowledge to run these systems.

A

The problem with tribal knowledge is that it doesn't provide any guarantee that policies are being enforced, you're, basically just hoping that workloads get deployed to the right place and that firewall rules get provisioned correctly and so on. Now, a lot of us are software engineers and we look at these kind of problems and we think ok. Well, we can build a solution.

A

You know Togo provision, firewall rules or to authorize requests, but the problem is that a lot of the time when we do that we end up hard-coding the policy decisions that are really important, that operators need to be able to control into the software that we that we build, and so we end up with these really tightly coupled hard coded policy decisions in the services and the applications that are actually really expensive and painful to maintain because they're so tightly, coupled with the business logic.

A

And so, if you want to change the policy or test the policy or understand the policy, you need to be intimately familiar with the application, and so operators and administrators are not able to easily change the policy and enforce new policies as they evolve over time.

A

So this is sort of these are some of the problems that we set out to solve only created the open policy agent project, so OPA or OPA. If you can call it whatever you want, is an open source general purpose policy engine and what that means is that you can take it and you can use it at any layer of the stack in any system.

A

Now, when you're using OPA, what you're doing is you're offloading policy decisions from your service, so you're decoupling, the policy decision from the enforcement piece and that's why you can basically take your service and you can you can use it to eat, or rather you can. You can offload policy decisions from your service and so, for example, if you're building like a micro service with an HTTP API, you need to authorize the requests that are coming in to that API.

A

So, for example, if your service is serving an HTTP API, then whenever it receives a request, it would query OPA and when it does that query, it would supply a bunch of input.

A

Data like the method and the path and so on that that inform the policy and then open would evaluate that input against all of the policies that it has loaded as well as data and context that you could add as well, and so the output of that decision might be like an allow or a deny, or something like that, and that gets sent back to your service so that it can be enforced. So the important thing here is that were decoupling policy decisions for policy enforcement.

A

Now, when we think about OPA when we when we think about how it fits into the architecture we like to think of it as a host local cache for policy decisions. So what this means is we're basically taking OPA and we're trying to join it. It's life cycle with a lifecycle of your service, so we run open the same machine as your service, whether using it as a library or a host level. Daemon or a sidecar doesn't really matter. It's the same model, you're offloading decisions from your service to OPA.

A

Now the reason why we want to do this, why we want to join the life cycles and why we want to deploy them together is because of two things. So, first of all, we want to reduce the amount of latency that we introduce into the request path in order to use OPA. If Oprah is running across the network on another machine, then every single time your service has to make a policy decision like every time it has to authorize a request. It's got to go across the network.

A

It's got a pea network, hop in order to get that decision, and so that obviously, is going to impact latency and performance and that's not really acceptable for the project.

A

The second reason- and actually it's a more it's more important reason- is around availability, so opens been designed to leverage this notion of fate, sharing, which basically means to couple life cycles of these other components and by deploying open on the same machine. Is your service you're guaranteed that as long as your service is up open is up and it can get decisions? It's not on another machine that could fail, or it's not on another machine separated by the network where the network could go down.

A

It sits on the same machine as your service, and so it can always get decision. So you want to leverage this, this architectural pattern known as phage sharing now in order to make all of this work. We've we've made certain design decisions with OPA, and so we designed it to be as lightweight as possible, and so to do that there are a couple things so, first of all, policies and data are all stored in memory.

A

So when you ask open for a policy decision, it's not calling out to an external database to get the policies or get the data that it needs. Moreover, when you ask for a policy decision, it doesn't call it to any other service. So all the decisions are handled locally on the machine with policy and data cached in memory. Now you can extend OPA to call out to other services that you know them in the policy. You can have something that doesn't get HTTP requests to get data if it needs to or you can take open.

A

You can extend it to to call out to like my sequel or something like that, where the policies might be stored or where additional context is stored, but on its own OPA is not going to do that. It serves decisions on the host that it's deployed on.

A

Ok, so let's take a look at how this works. So I've got my favorite friend here. Bob he's a cloud engineer, and this is an employee profile page. So we've got some employee details and performance reviews for Bob. Now this service, this application is actually implemented by a handful of micro services under the hood. So there's like a landing page that stitches everything together, there's a detailed service that provides employee details.

A

There's a performance review service that serves up the performance, reviews and so on, and so using this application we can actually demo a few different policies. But the way this is going to work is that when my browser asks the landing page for the for the fruit for the employee profile, the landing page is going to go to reviews and say give me the performance reviews. And then it's going to go to details and say give me the employee details and then it's going to join those things together and serve them to the browser.

A

Now, each one of these services is going to call out to an instance of oppa and asked for a policy decision at each one of these hops to say: should this request be allowed now in order to make that decision open needs to have certain data that it can reason about, and so in this case the services provide things like the method and the path and the user and so on, and so the policy is going to be written to evaluate against these things and produce decisions like a Lauer deny so the first policy we're going to show how you can implement is one that says that basically employees can see their own reviews as well as the reviews of their subordinates, so the people they manage.

A

The second policy that we're going to show is one that says that employees can see their own PII as well as HR HR special they can see PII now PII is just means personally identifiable information. It's just like a standard term for things like a social security number or you know a national health and insurance number or something like that.

A

Okay, so let me let me switch to my terminal here and I've got this running, so these services are running right now, on top of docker compose on my machine and they're, all asking a local instance of OPA for policy decisions and right now. This is the policy that OPA has loaded and hope is actually watching this policy for changes.

A

So whenever I change the file, the policy is going to update in OPA and you're gonna, see the changes reflected in the application, so right now, I'm not signed in you can see I'm not signed in here, but all the details are being displayed and all the reviews are being displayed, and so what's happening is that the services are querying.

A

This allow rule and they're asking what's the value of allow and by default it's gonna come in as it's gonna come back as false, but if one of these other rules in this file allow or and decide to allow, then the request will be allowed. So right now we're interested in performance reviews and we can see that it's going to allow if the input method is get and the input path. It matches this pattern. But what we want to do is restrict it so that only employees can see their performance reviews first of all.

A

So what I'm gonna do is say, get rid of that line and uncomment those two and then save. And now, if I refresh the page, you can see the performance reviews aren't displayed anymore. The reason for that is because the policy is deciding what the application should be able to present now I'm, not logged in, and so that's what we want. But if I log in to say Bob he's able to see his own performance reviews, but if I log in as like his coworker, say like Alice or analysis, the manager.

A

Sorry charlie, is the co-worker he's not able to see the the reviews either, but suppose I log in is Alice who happens to be Bob's manager right now. He can't she can't see the the performance reviews and so that doesn't really satisfy the policy we want. So, in order to handle the second part of the policy, we're gonna take this other rule here, we're gonna uncomment it, and now, when I refresh the page, the performance reviews show up now.

A

What I've done here is I've actually hard-coded the management chain of the organization into the policy and so I'm saying that Bob reports to Alice and Charlie reports Dallas now this data is hard-coded in the policy so that it's simple to demonstrate, but you could also just load this in as raw data like raw JSON or raw structured data through an API, and so you could pull data out of LDAP or ad or whatever system you use to keep track of this kind of information, and you could load it into open and use that to inform your policy decisions.

A

You could also get this information into open through something like a jot token, and so that way you don't need to take a dependency on on ad or something like that. Okay, so this demonstrates a simple idea of like controlling access to certain api's. Now. The other thing we want to do is we want to restrict access to sensitive data, in this case I'm logged in as Alice who's as a manager, but she can see the social security number here and that's not good social schemas like very sensitive.

A

Only HR should be able to see that and so I actually have another rule down below here called PII, and this PII rule is going to define what fields are actually containing PII, and so, if I go back to this this slide, you can see that the sorry, the detail, services integrated with OPA and so every time details receives a request. They not only asks should this be allowed, but it asks what are the fields that contain PII.

A

So it's querying for this PII decision, and so, if I refresh the page now, we can see we're logged in as Alice the manager, but the social security number is blanked out now. I've happened to like also hard-code who's, an HR. Here we've got scan and Anthony, so if I log in is say Ken that should not be displayed, so I go to Ken great. So now Ken can see the performance reviews and the social security number, and so I can actually change this.

A

If I want so say, Bob is actually getting like nervous about his old age and he doesn't want people to know his birth date. We can make that private as well. If I go and I sign out now the birthday and the social security are not being splayed. So this gives you an idea of how you can actually produce policy decisions that are not as boolean allowed and I or true/false values. You can actually generate arbitrary JSON data in your policies with OPA.

B

A

So what I want to do now is take a look at opus policy language, because that's the core thing that it provides to you as a user of the project. So the language is this declarative, high-level, declarative language and we call it Rago and it's it's designed so that you can like answer questions like. Should this user be allowed to do this operation on this resource? Or you know what annotations need to be added to new kubernetes deployments when they're created or which users can SSH into production machines and so on.

A

The language itself is actually really focused on two things: logic and data. It's not so. We know writing policies, you're, not really, thinking about like system calls or class hierarchies or which function you need to invoke on an object. Anything like that you're, just focusing on purely on the logic and the data that's relevant to policy, because policy is all about just making logic or making decisions which are based on logic and data, and so that's what you want from the language. So, let's, let's walk through this example.

A

So the the example in English says that employees may read their own reviews and the reviews of their subordinates the people they manage now in English this this published statement has sort of two parts to it, and so we're gonna actually create two separate rules to deal with this policy now, in order to actually evaluate the policy, we're going to need some input, data and so I'm gonna say that the method is set to get and the path is set to reviews Bob as an array and the user is set to Bob.

A

Now, I've represented the path as an array here, because oppa's language allows you to do pattern matching on data and you'll see that in a second. So the first thing we're gonna do is create. This rule called allow that you saw a minute ago, and you can basically understand this, as allow is true if input method matches get an input, path, matches reviews, employee, ID and input user matches employee ID. Now the meat of this policy is actually the last line.

A

Their input user matches employee ID, because employee ID is actually a variable and that variable is going to get bound to a value when oppa evaluates the rule against the input, and so in this case, employee ID gets bound to Bob. And if you just sort of walk through this in your head, you'll see that on the left-hand side it's going to be get and then reviews Bob and then Bob, and so all those things are equal and the rules going to succeed. So the statements in the body of the rule are basically ANDed together.

A

Now, let's try this with a different user. So say we have Alice requesting Bob's performance reviews.

A

In this case, employee-id is going to get replaced with Bob, but input user happens to be Alice, and so, when oppa gets to that last line, it's gonna fail and it's not going to find a way to prove that this request should be allowed, but suppose that alice is actually bob's manager and- and she should be allowed to see these reviews and so that fact that alice's bob's manager can just be represented as data as structured data that you put in the policy or that you load in through an API or that you include in the input and so on the bottom right here.

A

You can see I've defined a simple mapping that says that bob is managed by Alice and Alice is managed by Janet now in order to take in order to make use of this data or this context as we like to call it, you have to add another rule, and so this rule is gonna be very similar to the first one. We're gonna match on method and path, but then, instead of checking whether the user is equal to employee ID, we're gonna check.

A

If the user is equal to the result of looking up the employee ID in that data structure, and so then the same thing is gonna happen when we evaluate it's going to substitute Bob for employee ID, and then it's going to do a lookup to substitute Alice for that reference, and so then, obviously, when you when oppa goes through this, it's gonna find that all these things are okay, and so the request would be allowed. So the statements and the bodies of the rules are ANDed together and the statements in the head of the rule.

A

These allow statements are ordered together. So that's how you can understand these policies now so far, I've basically been talking about like microservice, API authorization or service authorization and one of the things that comes up. When you talk about API authorization. A lot is role based access control or are back and the question that people ask is well, isn't our back enough like why do I need anything else other than our back, and the answer is that in a lot of cases you don't actually need anything else. Our back is probably it could be sufficient.

A

It actually depends a lot on your use. Cases like how complex your use cases are, and actually how much you trust your users. So our back is good when you have simple use cases and you trust your users, but as soon as you cross that threshold, our back is not enough and then you're stuck and you need something else. So our back only knows about you know the resource, the name of the resource, the action and the subject.

A

If you're creating a kubernetes deployment or kubernetes pod, you might need to reason about all kinds of things that define that pod and our backs. Just not gonna be able to do that.

A

So if you need to write fine-grained policies that restrict or constrain the system or you need to leverage external context in your policy decisions, you're going to need to go beyond our back, but at the same time our back is nice in a sense, because it's so simple and the API gives you is fairly easy to understand, and so let's just implement our back with OPA.

A

So, in order to do that, we need to define a simple, are back model, and so I've got here roles and bindings, so bindings associated user with a role by name and then roles grant permission on an operation. So this is just like the are back model. You have in kubernetes it's a little bit simpler, but you could basically load.

A

This are back configuration into OPA as data just like the data that we had for the management chain now in order to makes use of this data again, you have to write a rule, and so this rule is going to look like this or gonna say. Allow is true, if there's a binding that matches the user and there's a role that matches the resource in the operation and there in the input and there's a role that and then rather end that the role matches the binding, and this is actually it.

A

So actually, if you just took this rule as is- and some data that looked like this, it would work you would have a basic are back system working now. The interesting thing about this. This rule that is different from what we showed you before- is that there's actually a search happening.

A

So this rule is searching over the are back data that we've loaded into OPA, so that first those first two expressions in the body are basically finding bindings that match the incoming user and then the second set of expressions is finding a role that matches the incoming resource in operation. Now, the interesting thing about this is that it's doing a search and with a search if the number of roles grows or the number of bindings grows, the search is gonna, start taking longer and longer.

A

If OPA wasn't smart, if it just evaluated these things naively, but even without changing this policy or changing the structure of the data in any way, there are a couple things that OPA can do to make these policies perform. Well so the first thing that opens going to do is it's going to partially evaluate your policies, so partial evaluation basically takes rules and data and it combines them and it outputs new, simplified rules.

A

So all the search and all the complex expressions in the original policy get it evaluated out, and then the thing you're left with are these nice simple policies that only contain references to unknown values like the input, the incoming requests and constants.

A

Now the nice thing about these simplified rules is that OPA can actually reason about them, because they're, simple enough and so open does reason about them and what it does is it builds an index out of these rule sets. So it actually builds a tri data structure by looking at this looking at the expressions and the rules and building it to an index out of them, and so in this case things like the incoming user and the incoming resource and the incoming operation all contribute to this.

A

This tri structure, so they become nodes in the Tri and then the constants become edges in the Tri. So OPA built an index out of these rules and then what it does with that index is it uses them to look up the rules that apply to the input whenever you execute a request.

A

So when your service queries for the value of allow it's going to supply the input like the user and the resource in the operation and then opens going to use that to quickly find all the rules that could possibly apply and then what happens? Is it open just evaluates those and when it does that it can skip all the other rules that don't apply to the input, so it can ignore those. So there could be hundreds of thousands of those rules and open doesn't have to care. It just skips right to the one that matters.

A

It evaluates that and it's done, and so when we use partial evaluation and we use rule indexing, we see Layton sees around 50 microseconds when you're talking about like 250 250, 250 roles and 250 bindings. But the really cool thing about is that, even as you scale the number of roles and then over roll bindings, the latency is like 60 microseconds at to that I. Don't order magnitude larger! So it's it opens scaling really well as your as your dataset grows. So I I went through that a little bit quickly.

A

There's there's a blog post on their blog posts on both of these things.

A

So if you're interested I recommend you check those out now at the getting in the talk, I was mentioning about how there are all these different policies and so whether you care about end-user data- or you know, kubernetes or terraform or whatever you're all dealing with policy and I- think that it's really easy as software engineers to look at these problems in isolation and decide that well, this needs to be solved independently, but I also think that it's possible to look at these problems and see a lot of commonality and when I see commonality as an art software engineer I like to build a general-purpose solution that solves it because then I don't have to go and reinvent all the performance.

A

Optimizations and all the tooling and get it right and then all the pain of that, and so you can actually use open today to enforce all kinds of policies across the stack so opens integrated with kubernetes for things like admission control and federated placement, you can actually even use it as an authorizer there. It's integrated with frameworks like spring and and service mesh projects like sto and linker D, to do API authorization on your micro services. You can do risk management over terraform changes in your CI CI pipelines.

A

You can actually do access control at the host level over who can run sudo commands or run execute assets or SSH into the box, and we've recently integrated with Kafka. So you can enforce access controls over who has access to Kafka, maybe based on context or other fine-grained permissions.

A

Now. The reason why this is possible is because we're treating all of these projects just as data they're, all just data they're, all just JSON or structured data that we load into open as input or as context.

A

So, regardless of the idiosyncratic way that these projects happen to represent their api's or their data, it doesn't matter because open doesn't care. It's not coupled to any of those data models in any way, and so that's why we call open general-purpose, because you can just apply it at any layer of the stack and just load data into it and write policy against it. Now.

A

Obviously, the policy has to apply meaning to that data, but OPA doesn't care that that's in the policy hope is not coupled to any of these things, and so this is some of the value that companies like Netflix, see when they're using OPA.

A

So Netflix was one of the early adopters of OPA and for them they have like a very complex environment with thousands of services and a number of different resource types that they want to enforce authorization over on different identity, types like VM and and batch jobs, and you know full-time employees versus contractors and so on, and they have all these different protocols and languages that they use to implement their service. And then, on top of all of that, they have strict requirements around latency.

A

They need to be able to tune the policies according to the application and the resource types, and they want to be able to test the policies to know that they're correct. If you just hard-coded all of this stuff into the service, you wouldn't be able to change it easily and you wouldn't be able to test it and so open lines up really well around flexibility and ability to capture intent.

A

It also helps that it performs really well because it doesn't introduce a significant amount of latency into their request path, and so today they have open integrated with HTTP and G. Rpc API is coffee producers and other things are coming. So we're super excited about that, if you're interested in more on how open or how Netflix is using OPA check out the the talk that we did with them at the last coop con.

A

So this is sort of where we're at today we have like 20-plus companies using OPA actively across a bunch of a bunch of different fields or industries like finance, service providers, IT companies, software vendors and they're, using OPA cross, the stack to enforce authorization, policies and micro services and orchestrators admission control, and so on.

A

They're controlling things of the hosts layer, they're trying to protect their data, and it's really neat to see them gain a lot of value out of having this general-purpose solution and so what we love in with OPA our new use cases, because we've already applied it for our back and a back and a Mission Control and data protection and so on. So if you have any use case, we'd love to hear about it, please bring it to us and we'd be happy to help you get started.

A

So it's really cool to see all this coming together, see this general-purpose solutions solving these problems, because what that means is that you don't have to re-implement the same optimizations you have to reimplemented the tooling, and so what I thought I would do is demo something new that we built just recently, which is an integration with vs code. So I, don't know how many people here use vs code, but it's a great ide just so I actually have the same policy.

A

That I was talking about before here in my vs code and there's a few things that I want to show. So the first is that you can actually just evaluate the policies in the IDE. So, for example, if I want to know what the value of allow is, I can do that, and it's good to tell them right now. It's telling me that it's true, if I, want to know what the value of all the rules in the package are. I can do that, so it tells me.

A

Allow is true: I've got a bunch of test data here, that's showing up selling the PII is SSN in it, and so it's basically going through all of these rules and evaluating them and telling me what the values are now, in addition to just evaluating everything in the package and that and the rules themselves, I can also actually just evaluate expressions in the bodies of the rules, and so this is really useful when you're debugging, because you want to know what the value of things are.

A

So, for example, here I can select this line and evaluate it, and it tells me that that's true and it's true, because I've actually got this file called input. Json here that's got a sample request in it, so the method here is get and I've selected. This line here, I method equals get now. If I do these next two lines what's gonna happen? Well, it's going to tell me the employee.

A

Id is Bob because it can tell that the first line is satisfied, but there's a variable in the second line, and so that gets pulled out of the path and bound as a variable there. So that's the same variable binding that happened when I walked through the policy on the slides, and so then I can go to the last expression again and it's the same output.

A

So this is really useful when you're writing the policies when you're debugging them, because you want to know what's going on, you want to sort of inspect the data and kind of figure out what's in there and how you can use it in your policy now once you've done that a little bit, you want to kind of move ahead and move to more kind of like production setting, and so you want to actually test that your policies are correct. You don't just want to be like evaluating them manually.

A

Every time you've made a change, and so we've actually got a test framework that you can use to write tests for your policies, and so this is what that looks like, and so here I've got tests for my different policies here, so I'm testing. That reviews is allowing input for when Bob asks for himself or when a manager asks for Bob's performance reviews and so on and I can go and I can just evaluate the entire workspace here and it'll. Tell me that all the tests are passing now.

A

If I made a mistake and I said that well, okay, coworkers to be able to see performance, reviews and I rerun. This lets test package test workspace.

A

We see that one test is failing now there is right there, so you can basically build up these Suites of unit tests for your policies and gain confidence that they're correct, but sometimes the the the set of policies is large and you want some sort of like higher level tooling for that, and so one of the things we started doing is building in test coverage, so I can run coverage on the workspace oops. It's failing so it's not going to generate the coverage. Let me fix that toggle coverage.

A

Now it's telling me all the lines that are covered in the policy, and so this the test is just another policy. Basically, so it's telling me that the test is totally covered and if I go look at my policy now we can see that all the all these lines are hit.

A

But if I go back to the test, say and say, I'd just get rid of all of these oops I mean it's get rid of this and I'm just gonna say test true, let's give it to that test entirely and now I do the coverage again? Okay!

A

Well now the test inputs not being used, but more importantly in my policy I'm, never hitting these rules, so I'm never hitting these these endpoints here, okay, so that's just a quick sort of demo of the the vs code, integration right now it's on github and we're hoping to get into the marketplace soon. Now we just haven't had time yet.

B

A

So hopefully, I've convinced everyone in the room that policy decisions should be decoupled from policy enforcement, because when you do that, you enable a general-purpose solution that can be optimized and support great tooling, if you're interested in the project I recommend you check out the website, we have tutorials for things like HTTP, API authorization, admission control, risk management, data protection and so on so go look at the website and try it try these things out and I hope that you'll find that you can actually leverage oppa to solve fundamental security and policy problems in your organization's, because that's why we built it.

A

So. Thank you very much. This is the repo police start on github. It kind of matters for open source projects, these days, I guess but yeah, that's it! Thank you.

B

Questions in the front.

A

So the question is: is there an integration for BIM? No other? There is an integration for vim, but it doesn't have all the evaluation in it. So it'll do syntax, highlighting and reformat your policies for you but yeah, but it could be extended. So.

A

So there's a startup, that's doing that right now open in the last release. We added a number of features that enable that so we have a thing: that'll tell open a download policies from a remote endpoint, it's very simple API. We have a thing that will tell open to upload status updates to a remote endpoint. So you know if your policies are synced correctly and we have something that'll also record decisions that Pope is making in memory and then periodically update batches of those to the to a remote endpoint as well.

A

So those api's are on the website. You can check them out and they're, pretty pretty simple to implement. So I think that, hopefully we see like these policy control plans popping up. Oh one, more I can, in the middle there, yeah.

A

Yeah, so if you're I don't know how you're doing it right now, but so the like so open exposes API is that allow you to load the data in so you could build that distribution piece that that basically makes very specific fine-grained updates to the data that's in Opa. So if your load, loading and large batches of JSON, then you'd probably want to use some of those api's. You could also check out the bundle API that I mentioned a minute ago.

A

That'll download things for you, so it depends what the I can chat with you afterwards about the specifics of that yeah. Let's chat afterwards about that. In the back there.

A

So the question is: can you support hierarchy in the policies right, yeah? So actually that's it. That example came from Netflix and for them they do have a hierarchy and they just basically represent that in the data and then the data can search over the hierarchy. So, yes, you can support hierarchies. To some extent. It depends on like what you're trying to do. If you're trying to do like a graph traversal, then it's not a great fit for that, but certain types of hierarchies are easily supported more.

B

Questions: okay, yeah, sorry again,.

A

I'm just trying remember now: okay yeah, so the integration today is is for authorization. It does allow you to present prompts to the user, so you can generate prompts and policy and then have those sent to the users. So, like one of the use, cases was that a company wanted to restrict. You could SSH in based on whether there was like a ticket open for that user for the application that's running on that box, and so the user would enter the ticket but that no, it won't create the user.

A

You can tell it to run commands, but I, don't yeah. I'd have to go back and look I can't remember: I didn't write that integration, so I, don't remember the details of it. Any other questions, if not I can wrap up no okay. Thank you very much.