Flatcar Container Linux Tech talks, 27 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Policy-driven access control - an introduction to OPA - Anders Eknert, Styra

Description

With our digital systems growing increasingly distributed and our tech stacks increasingly heterogeneous, we need to devise new models around policy and access control. In this presentation, we’ll introduce Open Policy Agent (OPA) - what problems it solves and how it unifies policy across the whole cloud native stack. After a brief introduction, we'll take a closer look at Rego, the policy language used by OPA, before exploring how OPA may be used for building guard rails around our Kubernetes clusters.

A

So I'm anders I work as a developer advocate for styra styra is the inventors and the the main maintainers of the open policy agent, which will be the topic of my presentation, so I have a long background in software development, uh primarily in identity systems uh and for the last two two and a half years I was working in a in a big project where we integrated oppa and uh in in an art in a big micro service architecture.

A

So that's kind of how I got involved in in oppa in the first place, so I've been on on both sides so to speak. uh When I, when I don't work uh with oppa, uh my main passions include cooking food and football and you'll find me on twitter and get out and so on, all right. So uh what problem are we trying to solve here or what's the challenge, so the challenge is basically to manage policy in increasingly distributed complex and heterogeneous systems.

A

So uh just the modern application stack in any larger company normally contains or entails this all these diverse and uh different uh languages, platforms, frameworks and so on. And of course we have uh all these uh targets for deployment. Our kubernetes environment, dockers, containers terraform.

A

And and cloud resources, of course, so, and then also course data. So any modern, like normally sized company, is going to have at least probably half of these technologies and the more the more the bigger the company, the more of these technologies, and the problem is that the these technologies all have their way of working with policy.

A

uh So that's the challenge and the goal of oppa is to unify policy enforcement across this cloud-native stack.

A

So so, really, what we're trying to do here is to to have one way of speaking policy, regardless of whether you're working with postgres uh aws resources or in golan.

A

So oppa is an open source, general purpose policy engine. It offers a unified tool and a framework for working with policy across the stack. What opa does it decouples policy from application logic, so meaning it kind of extracts? uh The part that is policy and it moves that out? Okay, sort of like you'd move data from your app and into your database.

A

That's kind of what oppa does for policy uh open is a policy decision ending though it doesn't do actual enforcement. So that's still up to you or your applications. How do you choose to act on these decisions?

A

So normally that could be like maybe responding with a status code of 401 or 403 or or maybe sending a message to some slack channel. But that's still up to your application, uh oppa is is basically just giving you that decision.

A

uh These policies, they're written in a language called rego, which is a declarative language which we'll look into uh more in a bit and since it is a general purpose policy engine, it's found use cases in uh in everything from kubernetes admission, control, uh app or microservice authorization, infrastructure policies, data source, filtering or data source access, uh and so on. So pretty much anywhere. Where you can, where you can find policy, you can find oppa and uh oppa is a vibrant, open source community we're we have.

A

I think these numbers are a little dated by now, so I think we have we're almost 200 contributors, uh 50 plus integrations listed and yeah. It's it's a it's a big and vibrant open source community, and uh not only is there oppa like the core uh policy engine, but there's also these kind of projects uh surrounding opa, such as conf test for for uh using uh rego and oppa on on configuration and and there's gatekeeper for uh for using opa as an admission controller and there's uh editor, plugins and so on.

A

But of course it's it's not just a hobbyist uh open source project, but oppa is used by some of the biggest companies in the world, and, if that, that's not enough to convince you, maybe this tweet will the open policy agent project is super dope. I finally have a framework that helps me translate written security policies into executable code for every layer of the stack. So that's pretty much that pretty much sums it all up. What elba is about?

A

Okay, so uh rigo, then or oppa? How does it? How does it work? How can oppa work with all these diverse uh technologies? uh So the way the policy decision model works? It's kind of like this there's normally a request coming in to your service and when I say service that could be anything that could be your.

B

A

But it might as well be kafka, it could be the linux power module or it could be docker. It could be the kubernetes api server. So anything uh anything that can intercept or accept requests is kind of a viable target. So so that's the model and and this service in turn turns to oppa to to for a decision.

A

Basically, so it sends a policy query, and this is all uh http, it's a rest api and it's like all just json, so any service or any any technology which can talk, http and which can talk json is can can ask opa for a decision and and of course, pretty much any service. The last 20 years or so can can do this. So that's why oppa can be so pervasive uh deployment, then the way it works. Oppa is itself it's it's a tiny, little uh self-contained binary. So it's a single file and it's lightweight.

A

So ideally you deploy them everywhere. There's no like one big fat, oppa per server that everyone would talk to, but rather, if you have uh eight or nine pods serving your app, then you'd have eight or nine oppas. You'd have one running inside of each pod and the normal kind of deployment pattern is often a side car in kubernetes or it's a daemon running on the same host and again applications. They talk to oppa through the opa rest api, but there are also a few other options available.

A

If you have a go app, you can you can talk to open or use opa as a go library, and there's also integrations for envoy istio-based service mesh meshes and there's also the option to compile your policy as a webassembly.

A

uh What about rigo, then, this policy language, it's a declarative, high-level policy, language which is used by oppa and when we say declarative it's it's kind of like sequel, you that you you've got brother rather than saying exactly how something should be done. You just specify what you want done and a policy is pretty much just a set of rules and any rule can can return uh a decision. So a decision could be true or false, or it could be a string.

A

It could be a list or it could be any uh nested object or or so so so it's it's really just json again and rigo uh offers uh 140, or I think it's almost 150 built-in functions dealing with things that are that you'll commonly want to deal with in policies such as json web tokens date and time, uh ip address ranges, math and so on, and rigo and oppa ships with a a unit test framework.

A

So uh as as you saw in the in the previous talk like the importance of of testing.

A

uh That's that's also one of the main benefits of kind of extracting policy from out of your applications that you can test your policy in isolation and you can deploy your policy uh separately from from your application code, so you can kind of have uh it can can have its own life cycle, it's a well-documented uh language and it's a well documented technology and there's also the opa playground or the regal playground where you can try things out and that's what we're gonna see in just one minute.

A

But one thing we should mention here before we we do. That is normally the policy in themselves. They they are useful, but they need data for in order to to make these decisions they need to know like who is the user? What endpoint are we trying to? Are you trying to reach? What operation are you trying to do?

A

So? There are a number of ways we can provide that to to oppa and the most common one is probably just as part of the query. So when you ask oppa, you also provide some data, so you say I am an admin. Am I allowed to to reach this endpoint, but if, if you need more data or you or you need uh data in other forms, you can also like push data into oppa uh through the opa rest api.

A

You can also provide whole data as in form of bundles, uh which oppa goes and fetch and fetches, and that's the last one there's also uh an http client that you can use from from inside of your policy. So if you really need to go, go out and fetch some data at policy evaluation time, that is also an option, and with that I'm going to hop over here to the rego playground where we can uh look at you know what what policy offering uh entails so to the left.

A

Here we have the policy window uh and to the to the right. We have some data so so this would. This is meant to simulate, maybe a simple rest service, a microservice or so where the service says some user here is trying to access this path.

A

The user's path and the method is, is get and the way we'd. The way. What the service then would expect is for us to say that, yes, this is allowed, or this is not allowed and we could, if we wanted to, we might also want to uh respond back with a reason. If we deny someone we might want to say no, you can't you can't access this end point because you don't have uh the role of a doctor or whatever, whatever is the requirement so again, and a policy is just a number of rules.

A

So, to start with, I'm going to add one rule and the kind of anatomy of a rule looks like this. The rule has a name, and it has a body and first of all the name has no real meaning to oppa.

A

We normally say things like allow, deny violation and so on and so forth, but to oppa they're all just words, so so these are just names that have meaning to us uh and the way these rules work is that if all uh the conditions inside of the body are true, then we say that the rule is true.

A

So if I just say something super simple, like I say that yeah this is true, and I evaluate this, I'm gonna see that the output with oppa decide here is that the allow rule is true and if I add another condition here where I say false, we're gonna see that uh the allowance rule is no longer true. In fact, it's no longer nothing because you know, but if, if something is not true, it's just undefined at least that's the default.

A

So if we want to change that, we might we might want to do something like this. We might want to say that by default, allow is equal to false. That seems like a pretty good uh default for for any like security policy. Doesn't it so we can say that that if we evaluate this again, we can see that now. uh Allow is false, even though these conditions are are not true, because that's kind of the fallback condition and if we uh have that removed, you can see that allow is not true.

A

So now so now at least no doubts, no matter what we're going to get sound decision, it's going to be something in the output, which is good, of course, if we want to uh parse that response in our client.

A

So of course uh this this is kind of a silly example. So, let's, let's actually do something useful here. You can see here that we have some data as part of the input. So so, let's use that. So we might want to say here: that's uh the user's endpoint, that's kind of a public endpoint, so anyone should be able to to to read that. So we say uh if inputpath this equal to users or or writers, let's see uh yeah, let's start with that, and the input method is equal to get so again.

A

If both of these conditions are true, then the rule is considered to be true. So if we change something here now or if we evaluate that yeah, that's still true, if we change something out of the input, so we're trying to put something in the users see that's uh the rule is no longer true. So so that's kind of super basic, uh the basics of how how regal rules work.

A

Let's change this back here uh and and of course, this is just when we we're probably going to have like hundreds of endpoints or at least uh a dozens of endpoints and and maybe several operations so the way we could do here, we could create uh new rules and we can aggregate him into like a single one. Another thing we could do is just we could work with what we call incremental rules uh and these are kind of forms.

A

So what we do here is just we create another rule with the same name and the way things work here like I said here that if all the rules in the body are true, then the rule is going to be true but you're outside of the bodies. If one of the rules are true, then the rule is true, so it's gonna and inside of the rules and or outside of it.

A

So if we say here now, for example- and let's do something a bit more exciting, we could say that there's also a user here, part of the input.

A

A

Okay, so so what we're going to say here is that any user should be able to modify their own data. So if there's a name here like anders so this is obviously this would be like slash we'd assume that the client have did this for us, but we could do that.

A

You know, but as well, if we wanted to so uh if we have the name of the user as the second path component, and the method then is put, we want to allow this if the name here is equal to the name of the user, so any user can modify their own uh their own data. That seems reasonable.

A

So we're going to say if the input path is equal to users.

A

And the next component here is equal to the user name. The input.

A

You can see that uh we can see. Are we allowed to do that? Yes, we are allowed to do that since those uh match and if we change that to I don't know, jane we try and evaluate. We can see that no we're no longer so and and again, if we do just a get request here, we can see. That's the longer.

A

That's no, that's not allowed either, but that's kind of that can that's it's kind of a bug here, maybe in our in our policy, because we, our intention here, was just that anyone can view uh users. They might not modify them, but so what we could really do here if we say like just if the first path component is equal to users, then we should be allowed okay, so that's uh policy offering in rego.

A

In I don't know five minutes and and and for now we didn't even use any of these kind of built-ins built-in functions, but we can only use very at the very like primitives of rigo.

A

It's still in only 30 lines. We managed to to actually offer a pretty useful uh all by basic policy. So that's rigo.

A

B

A

Hopping back here, uh and just since this is a cncf uh meetup, uh a topic which is always interesting is is, of course kubernetes and how and how does oppa kind of fit in there.

A

So so to answer that question. uh First, a brief look at the kubernetes api and how that works. So.

B

A

Basically works when you say cube, cdl apply and you and you try and deploy a new resource. What you're really trying to do? There is you're trying to save that to kubernetes database, which is of course xcd, but in.

B

A

Do that it needs that request needs to pass a series of modules, the authentication module, the authorization module and the admission controllers.

A

These modules are chainable, so there could be any number of authenticators authorizers or admission controllers um as on on the way to etsy and, of course, kubernetes ships with quite a few of these modules, some of them are more used and more commonly seen than others uh like the rbac module. I guess which pretty much anyone uses, but from an open perspective.

A

What's really interesting is, is the webhook module, so in any of these modules, you can say instead of consulting one of these built-ins I'd, rather send a request, an http request to some remote endpoints, with uh with this request, with with these uh resources that you're trying to persist, uh I'd rather send that to a remote endpoint and see what's what that has to say about it, so that sounds kind of familiar right. That's kind of web hook, model http and json body right.

A

That is exactly how opal operates, so we don't really do authentication leave that to others, but for for all these other modules, oppa is a perfect candidate and what we're going to just.

B

A

Bit deeper into now is the validating emission controller. Oppa is a great fit for both authorizers and mutating emission controllers. The validating admission controller is by far the the most popular module to extend. So that's why we?

A

Why we take a look at that today, what the validating admission controller really does it allows us to build policy based guardrails around our clusters, so we.

B

A

We can basically state a.

B

Number of rules.

A

Which should be enforced in our clusters, as as cluster administrators or or as just developers and and some of these pretty common enforcements include forcing or enforcing a specific docker registry, an internal company registry and other image constraints like you can't use the latest tag. You can't use any version below this or that and so on.

A

Very commonly you'll also you'll also find rules pertaining to labels. So you need in order to deploy this service, it needs to be marked with the name of your team. So we know who who to call when things go bad, it could be a call center. It could be anything like that.

A

Another pretty common uh case is for to verify like uh host or path uniqueness for ingress controllers and that's a bit more advanced since then. You also need to know the current state of your cluster. You can't just check the the kind of incoming resource. You also need to check, what's already out there, just to verify that uh you don't deploy a new application and it kind of takes over on a path already owned by somebody else or some other app.

A

You could also enforce tls amongst your services, deny insecure attributes like the host path volume mount and you can set limits on resource allocation and port security policies or really anything if there's any any kind of rule where you think this would make sense to standardize upon in our organization or in our team the validating admission controller, whether you use oppa or not.

A

This is there for you and it's it's one of those really really I'd say still underused uh tools, but it's one of the one of the best uh I'd say for kubernetes from from both from security and a compliance standpoint.

A

So, uh just to kind of reiterate here on rigo, you learned the basics here, uh just just a couple of minutes ago. So so what would it look like then? Well, as you can see, the basics are all the same. Here we have json in the input. The input looks a bit different from from what we saw in the in my example, but it's still just it's just json, so we have a pod a bit about to be admitted here and uh if we check the policy in the middle, it's a very simple policy.

A

It's a deny style policy and this one returns a set of messages.

A

So so so we can kind of respond to the to the user or admin why the the resource was denied, and we can see here that there's only one one single requirement here and we check that since, oh so so, there's not an input, request, object, metadata labels cost center.

B

A

There's not a cost center provided if there's not a cost center provided, then we can move on to the next line, which is just returning that message that every resource must have a cost center. So the response back from our oppa, it's going to be a deny. Every resource must have a call center label. So that's what you're going to see when you do cube cdl apply and then, of course you can just go back to your resource.

A

Add a label for cost center and then redeploy and everything will be fine, so that's kind of how we can enforce these policies uh across our clusters.

A

So uh worth mentioning, of course, is that running oppa and rigo uh for a single service, a single deployment or a couple of them.

A

It kind of works to just have uh just to just push your policy to a config map or whatever, but once you kind of start to roll out oppa as a side car for hundreds or thousands of microservices.

A

You might need a better tooling for that and that's where opus management apis come in uh and and what they really what they what they do is they offer a way to configure robot to to kind of reach out to remote endpoints in order to obtain policy to log decisions? That's another huge thing for like when you start to extract uh policy from your application logic, because now, all of a sudden you, you also have a golden opportunity to actually see what's going on in terms of decision.

A

These decisions no longer drown out in in the noise.

A

You have a status api for just kind of reporting status back to a management server and there's a discovery api for a periodically fetching configuration.

A

Okay, so where do you start, then, if you, if you think this sounds like a like, it would be something for you. I suggest, like start small, there's uh really, there's really no reason not to uh oppai is, and maybe just start with the playground, then in in one tab and maybe the docs in another and try try it out.

A

Maybe try these try a couple of big uh built-ins and just uh learn as you go, and then then start to look into the apps like close to those that you have experience with working and and try and identify which policies you you have there already, because it's not like you can choose whether to work with policy or not.

A

You always have policy just whether you do it in a nice way or not, and uh once you once you've uh identified some uh policy, you can start to delegate some of that to oppa and again you don't need to rewrite your whole app in a single setting. You can you can start with, maybe one end point, one operation or one roll or or whatever just start small and then and then kind of deploy and build experience from that.

A

And after that, you can start to consider these kind of management uh opportunities or management capabilities such as decision logging, how to serve how to share have like shared policy across hundreds of pods or applications, and a couple of uh free resources from from styrates to styra academy, which is a great learning resource which is absolutely free. There's the styra das, which offers many of these uh management capabilities once you've uh kind of grown beyond the basics and there's the opa slack.

A

If you and that's a fantastic community, although I think we're almost 5 000 people now so and and growing every day, so uh yeah, that's oppa, and uh with that I say thank.

B

You so the first question is, uh as a port security policy perspective, how uh how can we use opa on cluster level instead of built in community spot security policies? I mean without deploying a side card. Do you recommend gatekeeper project.

A

Yeah sure so uh yeah, so so what gatekeeper is is basically doing this. uh What we, what we uh looked at in terms of admission control, you can either just deploy like oppa the the vanilla version and have it just so what what gatekeeper does it offers some convenience?

A

On top of that, so you can you push your policies as as kubernetes objects, for example, so you can ask like custom resource definitions, so you can work with policy and so in in ways that are familiar to many like uh kubernetes admins, so so yeah I I can definitely recommend trying it out and it's it's a great replacement for uh pod security policies, but I think I, but I also think like just just trying trying out oppa like the regular vanilla oppa is, is probably at least I think it's it's a better way of learning, because then you really, then you really kind of confront it with okay.

A

This is the json object coming in, and this is the json object coming out. It doesn't really hide anything from from you, so it's kind of open the hard way if you, if you'd, like.

B

Thank you, andres. uh We have two more questions. uh First, is: does styra provide professional support if needed.

A

Yeah yeah yeah, of course, that that we do and and then the follow-up question was how many support hours do we have to buy to get uh such a t-shirt that we can. We can certainly uh uh send send you a t-shirt rb, so just just reach out to anders at styra uh after and I'll I'll make sure you get a t-shirt. Of course.

A

B

A

So styra we provide support for oppa and we also provide uh a management component for for oppa. So.

A