Fireside Chat: Implementing Authorization for Cloud Native Applications

Application modernization requires a plethora of different kinds of technological decisions, one of which is authorization. How do you control which actions your users can take and under what conditions? Modern applications require solving that problem throughout your application: from the frontend, to the backend, to the database, and so on. In this fireside chat, we will discuss best practices for using modern technologies like Kuma and Open Policy Agent to implement authorization within your application.

Transcription

Speaker1: [00:00:14] So first and foremost, obviously, you have contributed OPA to the community. Why don’t we start by explaining what OPA is?

Speaker2: [00:00:25] Sure, MarCO. Yeah, so OPA or open policy agent, it’s an open-source project that’s designed to really provide a unified solution to authorisation really across the cloud-native ecosystem of software. So there’s all kinds of software from Kubernetes to service mesh to databases and the goal for OPA to really give you one toolset one framework, one language for writing and enforcing policies authorization specifically across that entire collection of tools.

Speaker1: [00:00:55] So how did authorization change in this new cloud-native world?

Speaker2: [00:01:01] Now, that’s a good remark. You know, I think that when we whenever we think about cloud-native, I always think about moving to microservices, moving to cloud, changing our DevOps processes in terms of how we build and run software. And so as part of that, I think the security landscape has changed and what we see is now instead of having monolithic applications, we have these more microservices-based applications. So lots of different pieces of software all have to work together in order to deliver that that value for end users. And from an authorization point of view, then what that means is that you’ve got authorization that needs to be enforced in each and every one of those different pieces of software. Because as we all know, especially in this cloud-native space we’re in a spot where we were often deploying the software to all kinds of new environments all the time. And so what we want is sort of a zero trust model, a model where each piece of software, regardless how big or small, has its own security, its own authorization sort of baked in and part of it.

Speaker1: [00:02:01] So can we say that OPA, it’s a way to essentially abstract away this common authorization functionality away from each and every individual microservices in a different layer?

Speaker2: [00:02:16] Yeah, I like it. You know, I like how you describe it. I’ll often use the word de-couple so, you know, go ahead and pull that policy out of those individual pieces of software so that you can write the policy separately in a uniform way. You can manage them separately. You can, as you say, even go ahead and start thinking about how you abstract the weight policy so that you don’t. You can absolve yourself from having to worry about all the intricate details of each and every piece of software. You can instead think about higher level policies like, you know, insuring contractors can’t see CII.

Speaker1: [00:02:49] So how does OPA work? So if I were to remove the authorization code from my services into something else, these let’s call it the OPA layer. How how do I write these policies in the first place? How are they going to be enforced when a new request comes in? How does this work?

Speaker2: [00:03:09] Yeah, that’s a great question. So OPA really embodies this concept of policies code. And so the way that works, what that means is that Policy’s code says, Well, let’s divide. Let’s define a new file format. Just like we have file formats for images and movies, let’s define a file format for policy. And so you can write your policies in what sort of looks like code. And but importantly, it’s in its own file format. And so then what you also want is part of policies code is something like the OPA runtime engine, which knows when you load it with one of these policies exactly what decisions to make when it’s asked for decision. You also want to mention tooling around it, and it includes that as well. But then once you’ve got that, those two or three things and what you can do is you take any piece of software on the planet, whether it’s the Kubernetes API server or Kong mesh, and you configure them to actually send OPA requests for authorization decisions. And so then OPA been loaded with whatever policy files you decide to load it with. And now that that Kong Mesh or that Kubernetes API service says, Hey, what’s the decision? What’s the authorization decision? Opa, OPA returns it and then that that that source piece of software actually goes ahead and does that unfortunately very well.

Speaker1: [00:04:19] And and how do I deploy this piece of software than next to every service that I’m running because it’s obviously part of the lifecycle now, right? And so how do I go about making sure that these OPA validator or an agent is always up and running next to my services? How how how do your organization do that?

Speaker2: [00:04:42] Yeah. So in terms of deploying OPA, it’ll depend a little bit on the use case, remember? So OPA was designed to solve authorization across a cloud-native stack for Kubernetes or microservices service mesh and so on and so forth. So for something like Kubernetes, you would typically just deploy OPA a handful of Opas on a Kubernetes cluster on each of your Kubernetes clusters, and you can obviously do that in different ways for service mesh application. Often what we’ll see is people will run up as a side card next to each and every one of their microservices. And so, you know, again, there are different mechanisms that you can use for doing that. Some people will grow those things themselves. They will decide and they will build that into their software development life cycle processes. Some people will build dedicated control plane, some people will buy dedicated control planes as well. So it’s really up to sort of the user in the organization to decide exactly how they want to deploy.

Speaker1: [00:05:39] Very well. What kind of authorization policies can I write? Is it authorization policies for machines, for people, for users?

Speaker2: [00:05:52] Yeah, it’s not a great one, you know, one of the you know, we’ve answered one of those questions already, which is what kinds of policies didn’t write. We can write policies about Kubernetes or about microservices or about databases or whatever. But what you can also do in terms of answering that question is think about, is it people or machines that you’re actually trying to control the behavior of? And so the answer with OPA is really that you get to pick as an end-user like the policy language is sufficiently expressive that if you want to make and write and enforce policies about which microservices can talk to each other, microservices, then when you write the policies, you simply condition your, let’s say, allow [00:06:29] nice statements [00:06:30] on the service identities or the groups that those services belong to. If instead, you want to write policy for which end users can execute which APIs, then when you write those allow and [00:06:41] nice statements, [00:06:41] you condition them on the user identity or the token or the groups and claims that show up in that token. So it’s really up to you and you can even mix and match so you can write policies that say, allow this API call from this service. As long as it’s on behalf of this end user, it’s trying to interact with the application.

Speaker1: [00:07:01] So what’s the best practice to writing these policies? Because obviously there is a language that we can use, but how do I go about testing the policies, writing them? What kind of developer tooling do we have available to us when we think about writing and implementing open?

Speaker2: [00:07:21] Yeah, that’s great, and that goes back to, you know, when we talk about policy as code earlier we talked about, you know, you need a file format, you need a runtime engine and then you need some tooling that goes along with it. And so I’ll give you kind of two level two layers of answers. So OPA by itself has a collection of tools that make it possible to write unit tests over your policies, just like we write unit tests over traditional code. You can also do performance like profiling and benchmarking. So there’s a number of tools that you get along with. Opa also mentioned there are integrations for For Vs Code and Azure to help people offer so that they’ve they’ve got sort of a more integrated environment. And then there are also commercial options and you know, we offer one. It’s Styra, where kind of the idea is that you’ve got sort of an end-to-end policy lifecycle management solution all available out of the box. And that includes those kinds of testing that I talked about, but also sort of more in-depth testing that would say, for example, allow you to back test a new policy change using all the previous decisions that may be opus made for the past week or whatever. So that kind of back-testing is that kind of deep or testing is another obvious arrow in your quiver in terms of making sure that your policies are safe before you deploy them into production.

Speaker1: [00:08:36] That’s right. So Strya is essentially an implementation of an open server that our agents would communicate to in order to then enforce these policies?

Speaker2: [00:08:50] Yeah, that’s one way to say it, I think I think what the the the way I usually think about it is data plane control plane, so very much like a service mesh as a data plane, a control plane for. For us, the data plane, the thing that’s making decisions in the world is really OPA. And then what you also want is a control plane and management plane, that single pane of glass to give you visibility into all the OPAs. What how they’re how healthy are they? They it helps you obviously do policy authoring and distribution and like. So that’s kind of the analogy that I like to make for how OPA and Styra products correlate.

Speaker1: [00:09:26] So. Any organization has lots of services running around. There is lots of older services that perhaps already have some authorization code written within the service itself, like the old way. Let’s call it away. And then and then, of course, as we create more and more services in the future, we can think of implementing OPA to simplify how these services are being built. Would you say that OPA can works well for greenfield applications, but can also be adapted for brownfield? And if the latter is true, how do I go about that as an organization? Do I essentially remove all the existing code I have and try to replicate that in OPA? What’s the best practice to adopt OPA across existing services?

Speaker2: [00:10:18] That’s a great question. Certainly greenfield applications. That’s an easy one. I’d say. Pull your make sure that as you build new applications, you put the policy into OPA. I think for existing applications, we have seen people say, Hey, you know what? Authorization is hardcoded into our application, but there are a tremendous number of pain points around that. Like, I can’t change my policy if I find an I can’t change my authorization policy for the product because in order to do that, I’ve got to go find all those pieces of code that implement pieces of it and then and then update them all. And that’s just too hard. And so that, they said, is, look, look, let’s just have a project where we go and take this application and we go through it and pull out that authorization, move it over into OPA. The one thing, though, that all but also comment on is, you know, the service mesh is a great example where you can kind of mix and match those things right? Whereby adding that if you’re using a service mesh, you can hook OPA into that service mesh. In so doing, you can sort of transparently add an authorization layer to an existing application without having to touch at all. So, you know, that’s another option that we’ve seen for sure.

Speaker1: [00:11:30] So Kong and Styra are obviously partners, so we do are working with some common customers and users into implementing both the connectivity layer for all of these services with either a gate or a service mesh. And of course, also then provide them with control over how they build these open policies and how they write them. So let’s talk a little bit about Styra. So we mentioned already some of the things that Styra does. What else can Styra do if I’m serious about using open now?

Speaker2: [00:12:02] Well, so I think we’ve we’ve articulated this already in the sense that we have this very clear distinction between OPA being a piece of software that’s designed to make authorization decisions. And then we’ve got the Styra DAS or declarative authorization services we like to call it that was really designed to help you roll out OPA into the enterprise. And so that encompasses a bunch of things. So a control plan is one. How do you actually deploy policies to all those, maybe hundreds of OPAs that are out there in the world? How do you make sure that all those OPAs are healthy and that they’ve actually downloaded those policies correctly? How do you make sure that as you’re offering policy that the depending on the persona you have that you have the tools at your disposal to help you write policy in the way that you need to? We’ve actually discovered that different people throughout an organization want to think about policy at different sort of levels of abstraction, and people love to write policy in text files. Some people want to point and click interface. And so all of those things are available in site as well, along with features that help teams work together to sort of orchestrate how maybe the security team puts global policies in place that apply to maybe many different microservices. And so how do you orchestrate all that? So that’s kind of how we’d like to think about Styra offering, is it? It was designed to help you bring OPA into an enterprise successfully.

Speaker1: [00:13:25] Now this is very interesting. Obviously, we’re seeing this as being a trend in the industry. The more services developers are creating hundreds, thousands of them. And the more important it is to provide common abstractions for all sorts of functionality that we know it is going to be common across all of these services. Of course, Kong is very focused on the connectivity stack. Make sure that we don’t reinvent the wheel every time we create a new service, and it’s very complementary with the open use case to make sure that we don’t reinvent the wheel whenever we want to create authentication authorization rules on top of these services. As a matter of fact, with the partnership with Styra, like I said, we’re working with some enterprise customers that are implementing this tax in production and that are already seeing huge benefits into essentially accelerating the application development, while at the same time getting a more standardized security layer and connectivity layer across the board. Which allows them to have a more predictable and reliable infrastructure for their applications, I mean, these are certainly we don’t want our application teams to be doing these things. We want them to focus on what they do best and what they do best is the products, the users, the customers they need to make happy, whereas all of this infrastructure software, including the authorization layer, should be provided to them as a service. So Tim, you already mentioned we already spoke about what it does. OPA is also a CNCF project, and can you tell us a little bit more about that, that sense of journey?

Speaker2: [00:15:09] Uh, sure, yeah. Yeah, so when we started OPA, we knew in the very early days that it needed to be open-source, right? So every line in codes that have been written, we’ve done it, the open-source. And then what we also realized a little bit later was that the scene staff was this wonderful community of folks were all very energetic, wonderful to work with, had great ideas and moreover were very focused on this cloud-native ecosystem. And so we saw that there was just a great match there between the problems that we’re trying to solve, the kinds of people that we wanted to work with and the CNCF. And so at that point, we donated over to the CCF. And then for those folks who haven’t looked at the scenes yet before they got this sort of maturity ladder. And so it starts at sandbox and goes to incubate and then graduated. And so we went through that ladder. And at this point, it was a graduated CNCF project, which is the same sort of level of maturity as Kubernetes, Envoy, Prometheus and the like. So it’s been a great journey. I love working with the CNCF, and so I certainly recommend it.

Speaker1: [00:16:10] What are you excited about for the future?

Speaker2: [00:16:15] Oh, there’s so many things I’m excited about for the future. I think I hope, I hope we all are right. But you know, I think with Styra and authorization, I think we’re there are so many, so many opportunities here to really solve authorization deeply. I think working with Kong in the service space and really solving making sure that folks, as you say, don’t have to reinvent the wheel that in fact they can just walk up and say, You know what, I’m going to focus on my business value and I’m going to. That’s what I’m going to focus on and leave the authorization, the connectivity to, you know, Kong and style. I think that’s super exciting. But then I think more broadly as well, but at least for four open Kyra that there are so many different kinds of authorization problems that the can and need to be solved that that that is just such a such a rich arena in which to be working that I am excited every day I wake up. In order to do that, I get to work on that stuff.

Speaker1: [00:17:11] Can you tell us about some upcoming features Strya is building?

Speaker2: [00:17:16] Oh, sure. Yeah. So just today, timing worked out great. We just announced that DAS now has native support for Kong mesh as well as Kuma. So that’s super exciting to us. It means that now, you know, as you say, as we go to chat with those joint customers, you know, they know and have that native support and DAS for those for your service members. So we’re super stoked about that.

Speaker1: [00:17:42] Yeah, we mentioned these are the keynote yesterday as well. Opa is one of the features in one of the integrations that I was very excited about for Kong, for the Gateway and the mesh, essentially with Kong Gateway and Kong mesh. We now have full stack support for open, which means that we can protect and secure the same way traffic that’s entering at the edge or through a gateway, through an ingress point. And as well as we can expand and extend that security over the mesh with this full-stack OPA support. As a matter of fact, the mesh is probably the easiest way to deploy OPA. We bundled the OPA agent within the data plane proxy that we ship next to each service in such a way that with Kong mesh, we don’t have to run an additional agent. We can deploy the mesh and out of the box. The OPA agent is there ready to accept connections and enforce policies and connect with Styra and so on and so forth. So it’s probably one of the easiest way to deploy OPA across the board. So well, team, this is obviously very exciting news and. And is there anything else we’d like to add?

Speaker2: [00:18:58] Well, congratulations on the Gartner news. So that’s very exciting and well deserved, I think. You know, and beyond that, I am just looking forward to continuing to work with Kong and make sure that we can deliver on this connectivity and authorization joint vision. It’s super exciting.

Speaker1: [00:19:17] So what’s the best way to get started with OPA? So for anybody who is listening to us right now, they want to go check it out, play with it. What would you suggest is the best way to do that?

Speaker2: [00:19:28] Now, there are a couple of good sources that all that I’ll mention here, so the open policy agent website is a great one. Also, check out the playground there if you haven’t seen that, it’s linked. I’ll also mention that Styra got an academy that you know, walks you through the policy language. So once you sort of get your head wrapped around OPA, then that’s a great place to go to really understand how you write policies and what the ins and outs are there and sort of why it was designed the way it was. And then obviously also point you to Styra’s commercial product DAS. It’s you can sign up for free, you can try it out. And you know what I like about that more than anything, is that you get to see the whole vision for unified authorization, and it makes a bunch of things pretty easy to just get up and running. So definitely check that out. That’s a great source as well.

Speaker1: [00:20:16] Well, thank you, Tim, thank you for joining these live fireside chat here at Kong Summit. I hope to see you next year.

Speaker2: [00:20:24] This has been a blast, Marco, thanks for having me.