Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Open Policy Agent Deep Dive - Tim Hinrichs & Ash Narkar, Styra

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Open Policy Agent Deep Dive - Tim Hinrichs & Ash Narkar, Styra

Come to this session for a deep dive on some exciting new features in the OPA project presented by the project maintainers. This session will have plenty of time for Q&A!

https://sched.co/Zexz

A

Hello, thank you for sharing your time with us and thank you for joining us for the open policy agent deep dive session. My name is ash narker. I am a software engineer at styra and I'm one of the maintainers of the open policy agent.

A

We also have with us tim hendrix, he's the co-founder and cto at styra and is also a co-creator of oppa.

A

In today's talk, we will discuss oppa. We will talk about an api authorization use case in detail, talk about the new and the upcoming features being added to oppa and get updates from sub projects. So, let's get started last year we added the opa integration index, which showcases all the open source projects. Oppa is integrated with.

A

The purpose of this page is to make it easy to find a specific integration with opa or to browse oppa integrations within a specific category like service mesh, the oppa integration index pulls information about an integration, its blogs, tutorials videos code in this one single place, which provides a good resource for integration. Authors to model their oppa integrations.

A

A really good way to contribute to opa is to write an integration with a different project and then have it showcased on the oppa website. So we hope to see more opa integrations from you all in the future.

A

If you look at the cloud native landscape, it's constantly evolving, you have new projects being added every day: new databases, new service meshes and so on.

A

So now, if you're designing a system consisting of databases, api gateway service meshes you're likely going to deal with a lot of projects, some of which are shown on this slide, and your system is going to comprise of a lot of moving parts.

A

So if we focus on security, specifically authorization for such a diverse system, you can imagine a scenario where each of these projects are written in a different programming language and each have their own way of controlling access which may be tightly coupled to the underlying system.

A

And so you end up having no visibility into the security posture of your overall system.

A

Even from a point of view of flexibility.

A

If tomorrow you wanted to change, say the service mesh provider, you would have to spend time and effort in rewriting those same policies to conform to your new platform, and, you might say, we'll just write up policies in docs and wikis and we'll enforce them. That way, until you realize you have tens, hundreds or even thousands of microservices, and that wiki approach is no longer sustainable.

A

So what we need is a unified way to enforce policies across diverse systems in a highly performant manner, and this was one of the motivations behind creating the open policy agent. The goal is to unify policy enforcement across the stack.

A

So what is oppa oppa is an open source. General purpose policy engine.

A

When you use oper, you decouple the policy decision making on the policy enforcement, so your services can now offload policy decisions to oppa by executing a query. So let's understand this using this figure.

A

Imagine if you had a service and it can be any service at all. It can be a kubernetes api server. It can be your own custom service, an api gateway envoy, any service at all. Whenever your service gets a request, it's going to ask oppa for a policy decision by executing a query.

A

Oppa is going to evaluate that query based on the policy and data it has access to and send a decision back to your service where it gets enforced.

A

So you can see that we have decoupled the decision making from the policy enforcement.

A

The policy query itself can be any json value. So if you're doing kubernetes admission control, the policy query could be like a pod manifest or, if you're doing, ap authorization.

A

The pod query could be the request method, the path and so on, since oppa is not tied to any particular data format we say is a general purpose policy engine.

A

So what this means is that, as long as you give some structured data to oppa, it's going to give you a decision back and you write policies which makes sense for that data. Of course, even the policy decision itself can be any json value and then it's up to your service to interpret that decision and finally enforce it.

A

So, let's look at some of oppa's features at the core of oppa. Is a high level declarative language called as rego and with rego you can write policy decisions which are more than allowed denied through false. Yes, no, so you can write policy decisions which are sets which are objects basically again any json value or any composite value. Can be a decision you can deploy oppa as a sidecar, a host level daemon or you can embed it as a library as well.

A

All the policies and all the data oppa needs for evaluation are stored in memory, so you can think of oppa as a host level cache for your policy decisions.

A

Oppa does not have any decision time dependencies, so it doesn't have to talk to an external service for making a policy decision. However, you can extend oper to do that, but it's optional oppa does provide some management apis that allow you to pull policy and data from a remote service, upload status, information to a remote service and also upload decision logs to a remote service, along with the core policy engine oppa also provides a rich set of tooling. That allows you to profile your policies need to test your policies.

A

There are also integrations with vs code with wim and so on. We also have the rego playground where you can use, which you can use to experiment with your lego policies and also share them.

A

So these were some of oppa's features, a high level, declarative language, multiple deployment models, management apis for control and visibility, and a rich tooling set.

A

So now, let's look at the api authorization use case in a bit detail.

A

So, like I've said before, oppa is a general purpose policy engine you can use it with all of these different projects without having to write a single line of code. You can integrate oppa with each of these projects, but for this talk we will focus on the api authorization use case, so microservices improve the productivity of individual development teams by breaking down applications into smaller standalone paths, and hence many organizations today adopt microservice oriented architectures.

A

However, microservices do not solve age-old, distributed system problems like authentication, service discovery or authorization. In fact, these problems are more acute due to the heterogeneous and the ephemeral nature of microservice environments.

A

Imagine you have tens, hundreds or thousands of microservices and each microservice needs to decide whether every one of its thousands of api calls per second is authorized or not.

A

That's a pretty huge problem to solve, in fact, netflix who's. One of the leaders in microservices publicly talks about how important fine grin authorization is and how strict the performance and the availability demands are at scale.

A

So again, what we need is a unified way of understanding and controlling the authorization policies enforced by these diverse systems and by now I hope, the solution you may have guessed, it is oppa.

A

So, as mentioned before, oppa has multiple deployment models, and today we are going to focus on integrating opa with your service mesh or network proxy, so that you can enforce policies without having to change your services at all.

A

So let's look at an example using onward envoy, if you may not know, is a layer 7 proxy and communication bus designed for large modern service oriented architectures.

A

So if you're deploying your application stay on top of kubernetes inside your pod, you have your application container as well as an envoy sidecar as well.

A

So the way this typically works is that when your service gets a request, it's going to be handled by onboard, which then sends it to your application container, gets a response back and sends that back to the end user.

A

You can now inject opa in this flow using envoy's external authorization filter which calls out to an external authorization service to check if an incoming request is allowed or not. In this case, the external authorization service is going to be open and onward is going to provided the entire request context. So oppa can make an informed decision about the fate of the incoming request.

A

Oppa evaluates that query sends a decision back and if oppa denies, the request envoy sends a 403 back to the client if oppa allows the request like before onward, sends it to the application container, gets a response back and sends that response back to the end user.

A

So you can see here again that we have decoupled the policy decision making which is handled by oppa and the policy enforcement which is handled by envoy.

A

So in this way you can integrate oppa and envoy and you can enforce custom ingress policies, egress policies, service to service policies in a highly performant manner.

A

Now I'm going to hand it over to tim to talk about the new and the upcoming features being added to open.

B

Okay, thank you, ash. That was great. So now we're going to turn and look at new and future features so the first new future. The first new feature that we have available here is an update to webassembly. So remember that webassembly is this compilation approach that oppa supports that will take opel policies and compile them down into webassembly instructions.

B

So webassembly is just a binary instruction format for a virtual machine, and so the one of the benefits here is that you can take policies now compile them down into webassembly and then evaluate those policies in any programming language that has a webassembly runtime available. So that's pretty powerful because it reduces some overhead from just communicating with oppa when it's running as a sidecar, but it also makes it possible to run these policies in environments that, for example, don't allow you to run side cars, so we've had pretty good support for webassembly.

B

We can compile the entire language down into the binary instructions for webassembly, but what we haven't had support for entirely is the built-in functions that open provides.

B

So what this update really supports those those categories of built-ins described there, so arithmetic sets arrays some type, checking, built-ins and and most of the string manipulation operations as well, so that's new um and that support will continue uh to grow.

B

uh The other thing that's a bit new is that uh the opa build command has been updated, um and so now, when you're running uh the open, build command to con to construct these wasm um bundles, uh the format has changed a little bit and there are actually a couple of of opa build updates that I'll get to in a little bit the next new. The next new update here is really a new tool, so a benchmarking tool.

B

So this has sort of been inspired by go's benchmarking tool, suite the idea being that, let's suppose that you have one of these high frequency or high performance use cases, and so what you really need is some good visibility into how long it takes to evaluate the queries, you've written and so that's what the opa benchmarking tool is doing.

B

In contrast, the oppa profiler does give you similar kinds of output, but what it really does is it tells you where, in the code where, in your policies, there are hotspots so which parts of the code take the longest, but what opa profiling doesn't really do. A good job of is giving you absolute numbers around how long it takes to do evaluation, and so, if you're, using opa bench, you can see some of the output shown over there on the right hand side.

B

So the idea is openbench will run that same query that you give it many times in order to give you statistically significant results, and so that's what you see under here in the these histogram results, and then this nanoseconds per op is probably the the one number. If I had to pick one that you'd care about there in order to use the opa benchmark command, you can use just opa bench. So bench is a new sub command with an oppa, and then you give it some some data to load.

B

So the policy that you want to load as well as the query that you want to evaluate so that's that data.rboc.allow and so it'll just go ahead and run that query many times and then give you those results that you see on the right hand, side. The other way that you can use the benchmarking tool is through opa test. So you can go ahead and run opa test. The way you normally would and then, if you give it the dash dash bench flag, it'll go ahead and give you uh benchmarking results as well.

B

So that's exciting. If you're looking for high performance queries, I'd definitely check it out.

B

The next one on the list is decision, log mutation, so this is another new feature. Remember that oppa has the ability to create and record all the decisions that it's making in what I like to call a high fidelity, json log. So every time open makes a decision. It will record the input that it was provided, as well as the decision that it made, and then it can sort of send these in batches off to some external service.

B

So we've had for a while the ability to within oppa write policies that dictate which pieces of a decision log entry should be removed or or or deleted from that entry. Why? Because maybe that particular piece of data contains sensitive information, maybe you've passed in a jot and, and you want to make sure that nobody can use that jot before it expires.

B

So what's new, in fact, is that now opus supports the ability to not only delete but to update and add information to those decision logs, and so that's kind of what you see here. This is sort of similar in spirit to the kubernetes mutation policies, where what you're doing here is writing a policy that describes basically a json patch in this case it's saying here's a path, and I want to set the value of that path to this to this variable x.

B

um Now, one thing to keep in mind is that uh when oppa makes these changes to a decision log entry, it does actually record what it made changes to and so therefore, there's no way to to change the log. Without uh someone being aware that it was changed.

B

Oh thanks to domingo kaiser at front door uh for contributing this feature.

B

There are a few uh additional features that I'll mention here, so one of which is some of enhancements to partial evaluation. So remember that partial evaluation is a compilation technique. The idea is that you want to evaluate as much of a policy as you can at the time you build the bundle or at the time you you compile that policy as possible and in so doing the hope is that you've got less work to do at evaluation. Time, therefore, yielding faster evaluation results.

B

So in the past there have been some some restrictions on what portions of the policy get evaluated here in the upper left hand corner.

B

What you see is the the purple here is in is indicating a portion of the the policy that is known so that portion policy has no, uh it has no dependencies on the input, and so with this new, with these new enhancements, oppa can go ahead and evaluate that entire section of the policy uh and and obviously what it can't evaluate at the time it's compiled is anything that depends on input, and so that's that sort of that sort of lighter circle there that's pretty exciting uh one of the one of the byproducts of that is also um an updated open, build command.

B

So the idea behind opa, build um up to this point, has been that you can use opa build to generate wasm binaries, but we realize that the opa build command is, can also be used uh now for creating just regular rego bundles.

B

So if you've got a directory of rego files- and you want to build a bundle so that that bundle could be distributed to to oppas in in real life, then you can go ahead and use opa build, and then you just give it the rego files that you want to include in that bundle that second command. There allows you to not only build an open bundle, but also utilize that partial evaluation compilation technique and effectively optimize the bundle for evaluating the query that you've, given it there. So in this example example slash.

B

Allow is the path to the to the policy that you actually want to optimize for and then the dash one is telling oppa build to go ahead and optimize it at level one.

B

So what we're trying to do here is enhance the usability of of compilation features like partial evaluation, so that you can just choose an optimization level and in so doing, tell oppa how aggressive to be when it comes to building that bundle and then, like we said a slide or two ago, you can still use up a build to go ahead and target and build out wasm bundles. um Here, though, all you need to do is add the t flag for target and tell the opel build command to target wasm.

B

If you don't provide a dash t by default, it's going to just target rego the third, a new feature that I'll mention here is uh that there's a now a new parser for rego. So this has been pretty nice uh in terms of performance. It's roughly a hundred percent faster, so almost 2x faster on nearly all the benchmarks and then there's some cases that it's it's it's it's much much much faster.

B

So this is one of those examples where you just download a new version of opa and suddenly it starts running a bit faster and that's the same kind of thing that we see in this lower right hand corner this optimization for group by idioms. So it turns out that there are some uh common um and somewhat expensive uh patterns that we've seen people using when they're writing rego. So this particular kind of pattern is basically taking.

B

In this example, imagine you had a a list of network interfaces and the and for each network interface, what port it's it's uh been opened on, and so, let's suppose you want to turn that sort of flat uh collection of data into really a dictionary or a map from the interface to the array of ports that are open on that interface.

B

Well, that's a kind of a group by idiom, and so anyway, in the back end, what we've done is we've identified, there's an optimization that now looks for that kind of of pattern and goes ahead and and implements it more effectively. So, instead of it being an n squared operation now effectively, it becomes a linear time operation. Again, another great example where you just upgrade opa and and your policy starts to run faster.

B

That's it for features that are already in uh in the latest release of opa. So now, let's turn to some upcoming features, some work that is coming in that that that you may want to know about so the first one is that bundle so remember, bundles, as I I just explained, but but remember, oppa uses bundles to sort of download policy from an external service.

B

One of the new features here is that those bundles can now or or can now be signed, and so the idea being that oppo when it receives a bundle, if you, when you configure opa, you can tell it while only only activate bundles that have been properly signed, and you can give it all the all the keys that you need to, and so, if opa downloads a bundle and that bundle has not been properly signed, it will simply refuse to refuse to activate it and refuse to use it to do enforcement.

B

So that's pretty pretty powerful when it comes to ensuring the integrity of the bundles and the policies that oppa is enforcing thanks to ash and ashish for working on that.

B

uh The next new feature that's coming is that is always on tracing. So one of the things that sometimes people ask for is well okay, my service has asked for a decision from oppa. Oppa gave an answer. Maybe it's maybe it was an allow deny decision, and so the response was simply true false, but but that service maybe now needs to know a little bit more about why that decision was made.

B

And so one of the things we're working on is ensuring that um each time open makes a decision that it can provide a little bit more information back to the service if, if requested for that explains why that decision was made. So in this example, what we might do is just say for each of the virtual documents for each of the variables that are used in the policy which ones were actually successful and which ones were not.

B

And so, if you structure your policies correctly, that's a good way of getting a basic explanation out, thanks to patrick for working on that. The third upcoming feature is intellij, so opa does have a plugin for vs code. That does things like syntax, highlighting evaluating policy right there in the editor, doing testing doing building that kind of thing, and so we've got some folks working on doing the same thing for intellij.

B

So thanks to frankie assad, vincent and anders for working on that um that, together with so that would give you both intellij vs code uh and then, in addition, uh don't forget about the opa playground when you're looking for environments for developing policy, the last one on this slide is a new integration uh with mongodb.

B

So the idea here is that there are a number of databases where, uh like sql databases as well as elasticsearch, where there's been some early work on taking opa policies and compiling them or translating them down into the native query language for the database, compiling them down into sql or elastic's, query language so that you can write policies, authorization policies about, for example, which fields within a database.

B

A user is allowed to see and then compile them down and and infuse them sort of splice them into a query, that's being sent to that database so that it's the database itself. The database query engine itself, that is enforcing the authorization policy, and so this work with is looking at the same kind of thing.

B

uh Thanks to veneth and ash for for working on that.

B

Okay, so that about does it for the new uh and upcoming features. uh So now, let's turn and do a few updates on subprojects within oppa, so gatekeeper I'd expect most folks to to have a sense as to how, as to what gatekeeper, is so very quickly gatekeeper, takes opa and runs it and enforces oppa policies as a kubernetes admission controller, the idea being here that each and every time some end user goes ahead and tries to create a new pod or an ingress.

B

They go ahead and send that request to the cube api server. The api server sends that request through authentication authorization and finally mission control, and it's there at admission control that that gatekeeper, hooks opa in in order to make decisions as to is this pot or ingress configured correctly and safely for it to be deployed onto the onto the kube cluster in terms of new features. There's a good list there. I won't, I won't go through all of them. I will mention uh we.

B

We, the gatekeeper, did go through the cncf security review successfully, uh so that was that was great uh and then, in addition, um there's uh we've uh there's been the addition of pod security policies added to the the gatekeeper policy library, so those same pod security policies that are available in upstream kubernetes. uh There are now uh analogous policies that are available in gatekeeper, and that brings up the point that gatekeeper also remember, has a number of pre-built policies. um I think the list on the right there is is pretty well up to date.

B

The biggest new one is uh obviously the pod security policies that I mentioned. So if you're interested in using opa for admission control on kubernetes, I definitely suggest you check out gatekeeper.

B

There is now um a second sub project within opa called conf test we've. This has been announced publicly, but this is the first kubecon where we've gotten a chance to talk about it. So conf test is an application of oppo where it is designed to help developers run policies over configuration files, so those configuration files might be yaml files for kubernetes or or ini files, xml docker.

B

You see some of the examples there, the idea being that you can write opel policies over really any structured data that, at least from opus point of view, looks like json and so com test really makes it easy to run open policies over configuration files, whether those configuration files are on your developer, laptop or you know, in a ci cd pipeline or really anywhere.

B

So there are a couple of cool things about conf test, to mention, one of which is that list of input formats that the conf test supports so remember, oppa today, raw oppa supports mainly json and yaml, uh but conf test makes uh brings in a bunch of other uh input formats and and turns them into effectively a format json that that oppa can handle, and so that's that's quite powerful.

B

It also has a number of output formats, so there's a user friendly output format that just prints out the results of those of those policies. Here at the at the top. You can see an example of that. You simply run conf test and say test this deployment.yaml file and then it'll print out nicely exactly what the failures were.

B

So that's a nice, that's a nice thing from uh from a usability point of view, and then it also has a number of additional output formats that are supported to help with scripting and and using this in an automated process.

B

Finally, it's got a number of integrations for ci cd pipeline and ci cd, tooling, that you see there circle, ci, tech, town and github actions. That's really powerful, because a lot of people do like using conf test in ci cd pipelines to make sure that structured data structure, configuration files will pass the organization's policies before they're actually merged into that into that git. Repo welcome to conf test as a new opa project.

B

I certainly recommend you check it out if you're looking at writing open policies over configuration files- okay, so that does it uh for us for now, thanks so much for giving us your time uh definitely check us out online. uh Remember we're at uh opa's at openpolicyagent.org uh and then there's an active slack channel so definitely hop on there and ask questions. There's a community there! That would more than would love to help you out. So that's it for now, we'll open it up for q, a.