Kong Destination: Zero-Trust, 16 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Microservice Authorization with Open Policy Agent and Kuma

Description

CEO of Syra Tim Hinrichs demonstrates how OPA and Kuma can be used for microservices API authorization. For more information, view the blog post: https://bit.ly/38GZUaI

A

My name is tim hindrichs,, ceo and co-founder at styra.

A

We're going to be talking a little bit about microservice authorization,, especially in the context of zero trust.

A

And so that's the sort of jumping off point here, for what I want to talk about is really just a very simple observation,, which is that all these megatrends that we're seeing,.

A

We're all participating in around dev ops and move to micro services and a move to automation, self-service, cloud, ci/cd pipelines,.

A

All of those megatrends are fundamentally changing how we're building and running our software.

A

And we all know that., we all realize that..

A

What I want to point out, however,, is that a lot of the security that we have to put in place for those new applications, for those new platforms, for those ci/cd pipelines isn't.

A

Necessarily changing because of all those changes in processes.

A

And so, if I think about from a security point of view,, if I think about the shift toward microservices,, what I see roughly is it is like a huge increase in the number of apis that.

A

We now have to protect. and if I take a number,, maybe it's 10x right,, because every one of those little microservices was designed to expose an api.

A

And now, from a security point of view,, that's something that we need to protect.

A

If we think about the move to cloud,, one of the ramifications of cloud is that we fundamentally just have no control over the physical hardware that we're running our.

A

Software on. right., we can no longer just unplug the network, cable and as a security measure,. If we so desired.

A

And we think about ci/cd and automation,. What we're really thinking about is we're deploying those applications that we're building routinely to data centers located all.

A

Over the world. and so no longer can we sort of assume that there's a fairly static environment into which we're deploying our applications.

A

And what that means is that we no longer want to be relying on the environment, to protect, to secure those applications.

A

And then, if you think about devops and self service, the observation there is that, well,, we've just got more people who are responsible for operating a production environment. Now.

A

Than we did in the past when we had a dedicated dev team and dedicated operations, team.

A

And so zero trust in some sense, is is a great way of mitigating a lot of the security concerns for these. For these new cloud native approaches to software design,.

A

Implementation and operations., and so when I say, zero trust,. What I'm really talking about is I'm talking about really the aaa of security: authentication, authorization and accounting.

A

And my my my take on zero trust here is just that that security,, those three things at the very least, should follow all the services.

A

Those things should not only be implemented at the at the edge,. Those three things should be implemented with, should follow each and every service.

A

And so what I want to call out today is really thinking about authentication, authorization and accounting on each and every api..

A

And so, when I think about apis,, I'm talking about the apis that are coming up because they're externally facing for that application,, maybe they're internal apis that are only.

A

Used between services,, maybe they're, even third party apis like we're using on the public cloud or ci/cd system.

A

So I my belief here is that all those apis,, regardless whether what software system they're running on,, should be secured using that aaa paradigm.

A

And then I think, once you do that, that mitigates a whole lot of the concerns.

A

right., because what you have put in place now is you have controls over each and every api, over each and every action that gets to executed on all that software across your.

A

Software stack., and so all those all those internal apis that we have for micro, services, you've got controls over those all the public apis that you're using to implement your.

A

Cloud. you've got good tight controls over those.. All your ci/cd pipelines--you've got good controls over when applications get deployed,. What what what environments they get deployed to and so on.

A

Devops and self-service, once you've got authorization in place,. It's fine to have more people with access to production, because they're limited to and at least privileged sense,.

A

Only performing those actions that they should be able to perform ?.

A

Now, we're going to focus today on authorization,, so remember authorization of the problem of controlling actions that they have taken.

A

So those actions could be taken by end users, by people,, or those actions could be taken by by machines, by services.

A

And so today we're going to talk about we're going to sort of encompass both of those and we'll see examples of that.

A

And I want to just contrast this very quickly with authentication.

A

remember, authentication is the problem of how do you convince a computer system that you are? Who you say you are.

A

So that's usually solved with user usernames and thumbprints and passwords and the like.

A

Today, we're going to be focusing on authorization., so can alice, withdraw money from the account?. Can bob query the production database??

A

Can this service request invoices from another service and so on?.

A

So when I think about the application,, when I think about building these microservice applications, yes,, it's the case that in the old world, the monolithic world,, we had a.

A

Handful of different components that made up the application,, the gateway, the front in the back and the database.

A

And in this new microservice world,, we've got many, many more components., but what I'd argue is that those all those different components in the in the microservice architecture can be still lumped into some of the same categories of.

A

Functionality that we had in the old world. and that's what I've kind of tried to draw here,, which is, if you think, about a microservice application,, you can still break it down into the gateway components,. The.

A

Back and the front database.- and so I want to come out here- is the role that each of these different collection of components play in the overall in the context of authorization.

A

So if you got the gateway that it was a wonderful place to enforce api authorization for external, for customer facing, for user facing apis.

A

If you think about the backend,, that's that backend is really responsible for enforcing, maybe at a finer level of granularity, those those public, those external facing apis.

A

But the backend is also responsible for and the only place to enforce authorization controls over the internal apis within an application.

A

Why?, because those internal apis don't go through the gateway.

A

If you think about that frontend, well,, the key thing that the frontend is going to do, is it's not going to really enforce authorization policy,, but nevertheless,? It will be.

A

Responsible for understanding those authorization policies, so that when it renders the gui, that front end can make sure that it's not showing the user a trashcan icon, for.

A

Example,, when the user is not authorized to delete the resource.

A

So the knowledge of that of that authorization policy is really important for the front end to make the application have a great user experience.

A

Additionally, the front end,, especially for multitenant applications,, ends up helping those those administrative users actually set up the roles or the or the permissions that.

A

They're that their end users have within the application.

A

and if you think about the database,, it's is another great force to think about enforcing authorization, obviously.

A

But we've done this forever, making sure that only the correct users can read the correct rows. Columns from our databases.

A

And of course,, then the database is being used to store attributes that inform authorization, decisions.

A

We're going to look at the back end today, very quickly,, so when we think about putting authorisation controls in place for the back end,, there are a number of options that we.

A

Can consider. and remember, the idea here is that every time a back end service receives an api call,, we want to put an authorization policy in place so that we have good controls.

A

Over those apis., so one option for doing this is basically hard code. Those authorization policies into each and every microservice.

A

Now,, this is great from an availability and performance point of view..

A

These things are going to run super fast because they're written in java..

A

If the service is written in java or ruby or go.,.

A

And it gives the app developer a great deal of control over exactly what that policy is.

A

There a number of drawbacks, obviously here., if you've copied this, if you've. If you're trying to repeat this authorization policy in all your different services,, you've got to repeat that work.

A

You've got to implement in every language you're using..

A

The policies can therefore become inconsistent..

A

Enforcement can be inconsistent because at the end of the day,, it's it's just really up to the developer to make sure it's their calling into that authorization policy at the.

A

Right time. security reviews are slow here, because now the security team has to review each and every service.

A

There's no way the hot patch, there's no way to update that authorization. Authorization policy without redeploying the micro service.

A

And then logging.. This is an interesting one that I heard from the ciso a while ago,, and that was that from a ciso point of view, they've got hundreds of thousands of different.

A

Servers written by dozens of teams.

A

and now imagine that you're responsible for hooking all of the logs up into a ?.

A

So you can identify things like when a breach is happening or when it's already happened.

A

And what that means is that you've got a hundred different logging statements that all describe when an unauthorized access has happened.

A

And so now you've got a sort of canonical eyes,, all those generalize, all those,, so that your sim?.

A

Actually understands what an unauthorized access, is.

A

So, let's look at another option here for implementing authorization on the back end,, so one of which is you can just do the do the micro service thing.

A

Factor that authorization policy, that authorization logic out into a dedicated, microservice.

A

So here the idea is that every time microservice needs a decision,, an authorization decision,. It goes ahead and hits that authorization that dedicated authorization.

A

Microservice. there are number benefits: here. you're, not repeating work, right?. You've got one place to implement this.

A

authorization policies are super consistent because there's one place after all.

A

Security reviews are much faster because of security. Only really concerns about that authorization. Policy.

A

They know exactly where to look for it..

A

A hot patching is quick and easy.. You can just update that authorization, service.

A

A number drawbacks: here, though,, the biggest one- that I'll call out here is really availability and performance..

A

So if you think about a microservice architecture,, one of the things that you'll end up seeing is that an end user request might hit,, let's say, five different micro, services.

A

Every micro service hit incurs a network, ?

A

cost, and that's going to impact availability performance..

A

If you add to every one of those backend services, a second network, hop in order to check for authorization.

A

Well, now you suddenly double the number of network hops and that can have drastic that can drastically negatively impact your availability, performance, globally.

A

Ok,, so let's look at how we might address that.

A

well, one option: is you turn that centralized service into a distributed service.

A

And so now what you have is, instead of that authorization service running on a separate server as each of the micro services,. Now you distribute it.

A

So you've got an authorization service running on the same server as each and every microservice.

A

And what that does, is it eliminates that network.

A

But nevertheless, because it is effectively a distributed implementation of that centralized service,. You still have all the benefits you had in the last.

A

In the centralized service.

A

You don't repeat: work. you've got fast security, review, so and so forth.

A

The downside here, is, of course, now you've got you've, got to take a dependency on this sort of distributed authorization service.

A

Let's look at one final option: here,, and that is the service mesh,, and so the service mesh has a has the nice benefit.

A

The way that the service mesh works is it now you run the service mesh,, which means you've got basically a network proxy running on each of the microservices.

A

You've got that network proxy responsible for receiving and sending all of the apis to and from the service.

A

And so what you can do then do sort of integrate that microservice with that distributed authorization service.

A

And in so doing, you eliminate a lot of the drawbacks that we've seen in the previous option.

A

So certainly here you've got one place to to implement. Policy.

A

So there's no repeated work., the policies are consistent., security reviews are fast, and you can hot patch pretty straightforwardly.

A

Availability performance is great because now you've got authorization decisions to be made on the same server as the as the service itself.

A

You've got consistent enforcement now because you've actually integrated that service mesh with the authorization system itself.

A

So now each and every request that goes into or out of that microservice can automatically by the network proxy, go ahead and and send that request over to the.

A

Authorization, service.

A

and finally,. You don't have to modify the service at all., so you don't even need to know that that authorization service is running out. There.

A

Of course,, the downside of this or the drawback here is that you need to now deploy the mesh.

A

But if you're doing that anyway,, then this is a good. This is a good solution.

A

Ok, so hopefully that gives you a sense as to some of the different options that you could use to sort of, implement authorization for backend services.

A

And so I did want to zoom in a little bit on this last one,, this service mesh, and put some actual software names on there.

A

So kuma is a great way to think about putting a service mesh in place.

A

And and what you can also do for this authorization system is use the open policy agent.

A

And so here, I'll just talk to you this quickly to make sure we've all got this covered.

A

So the idea here is what you're, seeing here in this big dotted circle is the server.

A

So this is the one server. you've got your micro servers running on it. That's an instance, obviously.

A

You've also deployed the kuma data plane and the open policy agent, all on the same server.

A

So now what you imagine is that there's some request that comes in from the outside world that goes into the kuma data plan,, usually set that up via, like ip tables.

A

And so now kuma receives the incoming request.

A

What you can do, then, is hook up kuma to the open policy. Agent.

A

You can have kuma send the agent an authorization query that says, hey,. Is this api call, authorize or not?.

A

Opa returns that authorization decision.

A

Kuma is then responsible for enforcing that decision., so either kuma,. If it's rejected, will return,, let's say a 4 or 3 in the chart.

A

Otherwise,, if, if opa says that this api call is authorized,, kuma will go ahead and forward that request and step 4 back to the micro service.

A

The micro service will receive that as it always would, and then we'll construct a response in that response.

A

Kuma will go ahead and forward that back to the caller.

A

So that's kind of the flow of how information moves in this world where you've got a service mesh deployed and you've got an authorization system.

A

And obviously here, where we're articulating, how to do this with very concrete systems, kuma and the opa.

A

Now, once you put that in place, the question is, well, now, what kind of policy can you write?.

A

In here, I'm thinking specifically that you've got kuma with opa deployed.

A

And so here are a couple of examples. remember,. At the beginning I talked about how we could have service level policies,, which is controlling, which service talks to which other service over which apis.

A

They're also user level policies to control which end user can perform, which actions on which.

A

Apis., so if we just look at the service level policy, here, I've simplified it a little bit,, but the idea here is pretty simple.

A

This is sort of opa's language for expressing policies., and what you see here is that you're writing a very simple, allow statement that says: allowget requests on the path /pets.

A

If you're, looking at the source and the destination for for those service, identities.

A

And you have to decide on how you're going to deal with service identities., it's not something that that I'll cover today.

A

but but there are. There are well-known solutions for that.

A

If you want to look at the user level, policies, again,, looking at the policy itself, here, what you're doing is, again, you're writing a ?.

A

Statement. again, you're, going to say you're going to do a check on the method, you're going to do a check on the path.

A

But this time,, instead of looking at the headers for source and destination.

A

You're going to look at the token, so a lot of people do is they'll go ahead and for authentication, they'll use ?.

A

? json web tokens to go ahead and communicate the user attributes throughout the service mesh.

A

And what you can do, then, is hand that claim over to opa and have right policies that allow opa to sort of inspect the internals of those ?.

A

In order to understand what claims show up in the tokens.

A

All right. so there's the service level, policies, user level, policies.

A

I won't go into detail here just for time., but one of the other nice things that you can do once you have that deployed is is write, policies that rely on external data.

A

So data about what's going on in the world., and so here you could use ldap for employee information or you could use any kind of really external data that you like.

A

Ok,, so now, what we've done is we sort of looked at how opa can be used, along with kuma, to implement api authorization at the at the service mesh level for backend.

A

Services., but one of the other things that I remember I articulated was it really. Authorization is not just a problem for the back end,. It's a problem for the it needs to.

A

Be solved at the gateway and the front of the database., and so the other thing you can do here is think about, well,. How would I implement authorization for the gateway?.

A

So one option that you could go with is: if you're running,, let's say kong for your gateway,, you could go ahead and connect that to opa as well, so that you can enforce api.

A

Authorization at the gateway level.- this is one of the nice things about opa, and what it was designed to solve is that you can go ahead and use opa for really any use case,. If you like,, is not tied in any way to.

A

Kuma., it is a general purpose. Policy.

A

And so a lot of people ask the question, well,. Then how does it work if, in fact it is this general-purpose solution?.

A

So I'll go through this very briefly.. The idea here is that you have some service that decides it needs an authorization decision.

A

That service goes ahead and sends the policy query to opa,, as you saw in the diagram a couple of minutes ago, with kuma.

A

Opa returned the policy decision to that service..

A

Now the service is responsible for enforcing the decision.

A

Opa, however, is responsible for making the decision., so we already saw that with kuma., but a couple of the key things as to why opa can be used for all these different use. Cases that you saw on the last slide are shown here.

A

So one of which is that that policy query is really just an arbitrary chunk of json.

A

Opa doesn't know or care what a method, a user, a path actually are.

A

It wasn't built into opa., there's no go code and opa that understand what those things are.

A

And because of that, I as a policy author, well,, I know what a user method and a path is.

A

So when I wrote the policies that I showed you a couple of slides ago,, I can write the policies to do the right. Thing.

A

The other thing that I'll call out here is really that that policy decision, the policy decision that overturns again, yes, it can be used to return, ?.

A

? decisions to give you straight up authorization or classic authorization,, but you can also return arbitrary, json, values.

A

Again,, this is really useful because, when you're, integrating with,, let's say, the kuma data plane,, you might return.

A

Not only is this request allowed or denied,, but what's the status code or maybe what are the additional headers that need to be passed along to the microservices at the back end?.

A

Ok, well, now I've talked a little bit about how opa can be used across all these different components of the application,. But why stop there?.

A

Was designed to solve the authorization more generally,, the policy problem across the cloud native stack.

A

We focus so far on the application, because that was where we started,, but really opa is being used across the stack to solve authorization and more generally, policy.

A

Problems at what I like to call the three pillars of cloud native,, which are ci/cd pipelines,: the platform that we're running applications on,, as well as the applications.

A

Themselves., so you see on this slide, you see sort of the one we always show to people about how and where opa can and has been deployed in production.

A

So, each and every one of these categories of use- cases, we've seen people deploy opa in production to solve authorization policy, problems.

A

We've talked here about the sort of application of the service mesh level,, the gateway level.

A

Using opa to do in mission control within kubernetes is another popular one.

A

I saw an earlier talk in the agenda for that..

A

Using opa like within a pipeline is pretty popular,, especially around using it, with with sort of to control what resources on public cloud get deployed.

A

With terraform., we even see people use it for ssh control, as well.

A

So the last thought I'll leave you with is this picture is, I think, pretty good in terms of of what you get with opa.

A

In a service mesh setting,, you may have five hundred instances of your micro services split across across all kinds of data. Centers.

A

And so, if you've got five hundred instances of your microservices,, but you end up with when you're running opa as a sidecar,, just like you would with the kuma data point,, you.

A

End up with five hundred copies of opa,, each of which need to have policies deployed,, each of which need to have status updates,, each of which you need to write policy. For.

A

And so, at the end of the day,, what you do need to add to opa is a control plane,, a way of understanding and controlling all of those opas.

A

And so one option for this is, is what we call styra's declarative authorization service.

A

It is, it was designed from day one to be a control plane for opa.

A

It can be used to control opas across all these different use. Cases.

A

It has specialized support for kubernetes and for for the service mesh.

A

And so I definitely check it out. there is a free version that you can sign up. For.

A

so definitely check that out. If you can.

A

the way I always like to think about it is that control plane., but it also what it provides, is really a vertically integrated policy as code solution that was really designed for the enterprise.

A

So go ahead and check that out. If you can.

A

shameless plug here for sure.

A

ok?, and I think that with that, I will open it up for any questions. You might have.

B

B

Do we authorize protocols like mysql or any other app talking plain tcp and not http?.

A

Yeah, so really,, the enforcement question that we see is the way to think about using opa is that you would run it next to a service that knows how to handle,.

A

Decrypt or not decrypt the knows how to pull out the interesting bits out of out of whatever protocols being used.

A

So opa was not designed: to, like, watch a network, watch network protocols and figure out that this is a sql connection or anything else.

A

So so this picture that we have here is pretty accurate,, which is the way you think about this,. Is that you the way you.

A

Think about opa is that you'll go ahead and and connect it to something that is responsible for that. Has the domain knowledge to make those decisions.

A

So in this example, one thing you can do that that's a bit different is that you can have opatranslate the policy into additional where clauses that can then be.

A

Spliced into those sql queries.

A

opa itself doesn't know about sql.. You need, something sitting outside of opa to actually orchestrate that.