Styra DAS & Kong Mesh: Policy-as-Code to Control Microservice-Based Communication at Scale

It wasn’t that long ago that coarse-grained access control lists (ACL) rules on a network firewall were enough to satisfy security requirements. As application architectures have become more distributed — composed of multiple microservices, housed in containers, the way we control access between resources has evolved from focusing on hosts/IPs to one based on services and message payloads. That’s why our team here at Styra created Open Policy Agent, which supports a cloud-native, declarative, policy-as-code model for defining and enforcing authorization and other policies.

Join us as we share how world-class organizations are using Kong Mesh and API Gateway with Styra Declarative Authorization Service (DAS) to address these challenges, accelerate their microservices strategy and provide their teams of operators and developers with a platform that deliver the ability to:

• Manage policy-as-code as part of an established GitOps process
• Validate the impact of policy changes before committing or deploying
• Distribute policy across clusters, clouds and teams
• Monitor authorization decisions (in real-time and historically) to ensure policy works as expected

Transcription

Speaker1: [00:00:06] Hi and welcome to today’s session. Today, we’re going to walk through policy as code to control microservice based communication at scale. Before we kind of dive right into a DAC, I do want to just set the stage. It is my hope that we can get to a demo today and know it is just a quick twenty, twenty five minute session. So I’ll definitely do my best to get through our deck as quick as possible so we can see things in action. But if we don’t get to a demo today, I do want to encourage you all to just reach out. If something we discussed today sparked your interest or if you want to discuss it further or see it in action. A little introduction about myself is that I began my career on the IT side, working in desktop virtualization and networking and cloud computing technologies early on. And then I dove into the security space where I was able to focus on application development and sensitive data, DNS research and connected devices later on in my career. I think today what I really love is that with Styra, I’m able to focus on the vision and mission alongside our fabulous engineers and operators like yourselves in your journey to kind of flourishing as you all adopt a cloud native approach. And so I think today, as we kind of work through this and hopefully a demo. Let’s dive in and set the stage for kind of where we are today as an industry and how we got here. What’s worked for organizations, what’s not worked for organizations and how we’ve transformed. And so at any time, please feel free to just kind of ping ping us and chat. We’ll do chat at the end if that’s OK with everyone. And then I’ll move through those questions. And if we don’t get to the questions, I’ll make sure to follow up with you guys individually.

[00:01:55] So what we’ve seen is this impact of microservices on authorization and what and what that means is that organizations today like yourselves are delivering code faster and more reliably. And what that’s become is something that’s essential to business ops. And so we’ve seen that industry leaders have embraced this by implementing a true kind of cloud native approach with containerised applications. And so where that comes into play is on the left hand side, you see the monolithic applications, how we were creating applications in the past and how some organizations still today are creating applications because of the simplicity of it, right? You have one code base. You understand where all of that is. You can take it down, you can analyze that code, you can draw it back up, but then you have on the right hand side this marker microservices architecture. And what that provides is this kind of decomposition of where each application or app component is able to reside in a separate container and allow kind of the software teams have the ability to test, run, update or even delete each service without interfering with any of the other components. And so one example that I really like that one of our founders uses frequently is a financial institution in the applications that they run. And so like many of us on this call and talking today, participate in online banking. And when you think about how that online banking application is executed, organizations today could be running anywhere from tens to hundreds of services to make sure that the needs of the end user are being met. And so if I log on today, I might see my savings account and my checking account and a promotion or more, and each of those by themselves could be a service or a set of services, right? And the ability to kind of decouple that from a singular code base can be absolutely beneficial and has been and obviously you guys are at the Kong summit, so you know a lot about that. So with all of these, you know, containers and the associated services policies typically siloed, you know, and it’s typically in different languages like Python or C-sharp or Ruby, and it’s built on custom coded logic. Right. And this is where it’s kind of absolutely essential to have a unified authorization for all applications. So you can kind of ensure how those applications respond.

Speaker1: [00:04:40] You can verify if guardrails are needed and then, you know, even where to run clusters. Most cost-effectively. And so this is where we kind of dive into what Styra does and what we created. And so we’ll jump over to the next slide, which is open policy. And if you’re not familiar, this is where I’m just going to go into a little spiel of what OPA is and if you are familiar. Thank you so much for being part of our community. We are tremendously grateful for the adoption that we’ve had. And so our founders, Tim Torin and Timu, really wanted to reinvent the way that folks were thinking about authorization across the stack. And while we have a fair amount of customers that are at the forefront of this migration and really adapting a cloud native strategy, there are organizations that are just beginning their journey and are working to break down this monolithic applications. We saw a couple of slides ago and work towards a cloud driven architecture that that really kind of focuses around microservices. And so what we did is we built and I say we, but obviously that’s Tim Taun and who in their hard work. We built an agnostic framework that works across the tech stack. So it’s a general purpose policy engine that can work across traditional or modern tech stocks. And that’s OPA. And we donated it to the CNCF, and we are very fortunate to call it a graduated project at this point, which is very heartwarming and great for our organization.

Speaker1: [00:06:22] And so what OPA allows organizations at its fundamental value to do is decouple that policy from the services code so that you can run the analysis. You can release or review policies without really sacrificing the availability or performance of those applications. And so what this really means is that teams can stop using those different policy languages and different policy models and different policy APIs for every product and service, and they can really start to wrap that around one single language. And that today at the bottom left of this diagram, you’ll see it says policy is written in Rego, and that is our language for OPA, and that’s universally accepted. And so what does that kind of really mean for folks and how are different ways that we can implement this? And so the biggest one that we kind of see is managing policy as code, as part of an established GitOps process. And so there’s a couple of reasons why developers and platform engineers integrate policy as code into their current guidance process. And one of the really crucial pieces is that policy as code saves these engineers and dev ops teams from having to manually review hundreds of lines of code and config code. And another really valuable reason is that it accelerates the application development and deployment.

Speaker1: [00:07:57] So it solves for many of those kind of change management hurdles that slow the development pipeline down, you know, and then we see some other benefits. Another really great benefit there would be like on the development side, policy as code really kind of helps our app developers learn and understand what you know, what the is config security compliance policies are and how to adhere to them. And so, for example, you know, a developer may not remember, you know, or may not have a reason to know that when deploying a load balancer onto khub in CSS is or is it not sanctioned and policy is code would solve for that problem automatically. So. I think the biggest piece here is that is this significant time-saver in terms of policy creation, I think when taking the time to learn Rego as another language that you have to learn and that being, you know, a daunting task, I think within a day, day and a half, that’s something that can be easily processed. And you all are probably much smarter than me in terms of processing that. So I’m sure that it would take you significantly less time. But you know, the biggest thing I think here is that we some companies already apply policy to their build pipelines and typically use kind of a number of ad hoc scripts. And OPA really kind of enables teams instead of taking those like implicit policies and running them, it makes it declarative and explicit, right? And so one example we saw was a company that was prior to using OPA.

Speaker1: [00:09:45] They wanted to import all of their existing security and corporate policies into their production pipeline. And when they consider the amount of hours they would spend coding this, a specific project, it really ended up not being feasible for their team just because of bandwidth. And with OPA, the company was able to kind of instead create new policies that then were enforceable across each of their cloud environments, saving them a significant amount of time down the road when they would have to manually do it right. So. You know, when we look at it, policy as code is, of course, policy or is of course code right, so that means that these automated checks happen in a way that is already familiar and comfortable for us, right? And it makes it significantly easier as we’re building and deploying cloud-native software, right? And so if we look at this entire diagram as Kubernetes and container-based strategies are kind of our clear future in the cloud-native development team, you know, space using a GitOp strategy to accelerate that development time frame and kind of reduce the chance of cloud misconfigurations is really, really kind of beneficial. And so really having this simple or scalable way to manage policy through the app lifecycle and distribute it across every pipeline cluster or even cloud right in the organization really is where OPA power is right.

Speaker1: [00:11:35] And so as we kind of dive in, what does this all have to do with Kong and what does this all have to do with Styra? If we’ve talked about OPA as an open policy agent, that, you know, is an open-source tool, what does that really mean as we kind of dive into Kong and Styra as an organization? And so the really kind of amazing thing that happened earlier this year is that in version 1.2, Kong built-in OPA into a Kong Mesh and Kong gateway. So essentially what they did is they allowed customers to not have to run an additional sidecar of OPA, which is is really kind of awesome for them to build in. I mean, I think it speaks volumes to the community adopting OPA. And to follow that announcement, I did want to give you guys kind of a sneak peek. You will if you do follow our blog or on our email list or follow us on social, you will hear about it more tomorrow. But today I did want to share something really kind of cool that we are thrilled about is we’re reciprocating the love that Kong showed us earlier this year, and we are providing native support of Kong mesh within Styra Das are declarative authorization platform.

Speaker1: [00:12:55] And so what we’ve we’ve done there is we’ve enabled kind of our users and our customers to combine the stellar service mesh solution of Kong Mesh with the only authorization management platform or solution on the market today. And so while we’re talking about service mesh today, I think it’s also important to acknowledge that still does allow teams to manage policy across a broad spectrum of systems, right? So we talked a little bit about Kubernetes, public cloud terraform, other system types as well. You know, we touched a little bit about how organizations are decoupling policy from the code base for software to unify enforcement of that policy across the stack. I think with this, this addition that we’ve made that we’re going to announce tomorrow that you guys are getting a sneak peek on is organizations can now start to look at this cloud-native application piece, you know, looking at it through the lens of dynamic policy enabled traffic control, which is pretty stellar. And so what we’ve seen in some of our beta testing in some of those pieces is the ability to govern, monitor and audit that traffic flow and see those decisions for real-time verification, right? We’ve seen the ability to automate policy as code-based control for services, which is, you know, it seems so simple, but it’s really kind of wonderful when you see the two control planes of Kong mesh and star does really meeting in the middle there.

Speaker1: [00:14:47] We have the increased application reliability, you know, with policy based traffic management, and that’s another benefit that we’ve seen our customers pop out with. Based on this, this integration, and I think as we kind of dive in a little bit more, I think the biggest thing here is that we do want to make sure that we’re meeting people where they’re they’re organizing, right, which is why OPA is so easy to deploy right on any, any service and any system. And so as we look at what that means, you know, obviously you have on the left hand side, but you have Styra DAS on the right hand side. And what this kind of looks like from a very simplistic diagram, which is service A. And then there’s an open that’s a side car. I think we mentioned earlier that, you know, obviously with mesh, you do not need an additional sidecar. So this diagram will look very, very different if you are running Congress. But if you were running Sasikumar, you would run the addition of a side car. So I think the big thing here is that when we look at all of the ways in which this authorization control plane can help, we look at some things like. There’s a performance and availability piece, right, so there’s no need for kind of this network hop and authorization decisions now with all of this in place are under one millisecond, which is kind of phenomenal when you’re talking about that making much of a difference when you have so many different services running.

Speaker1: [00:16:21] You know, the other piece we talked about is it being a control plane? And so that what that control plane gets you as a single pane of glass? And I know that’s pretty much a marketing turn term. But what Styra DAS gives you is the ability to look at immediately all of the insight that we have for each individual OPA and control all of those individual OPAs right, which is that if you have a specific policy for your organization, you can deploy that to all or some or many of your OPAS without having to do it individually, which is what some organizations. Um, you know, you can also understand the impact of a policy change that you’re making, right? So the biggest piece is that you can validate. So if I don’t, if I want to push a new policy live, I’m not going to break anything right? I can see what it’s going to break before it does it because I can validate that piece and then I can take a look back and say, OK, you know, it did break a few things. I need to make a few tweaks here or there. The really big piece, you know, when we talked about the kit process is that you can collaborate with your teammates, and that’s by composing policies and libraries using get-based peer review.

Speaker1: [00:17:40] And so that’s really kind of a stellar piece as well. And then leverage a production-ready microservice authorization platform that adapts to the new way. We have teams and technology stood up. And so that’s another really great one that we see today. And then I think the biggest part here would be just to partner with the team that created and maintains OPA, you know, and let Styra DAS doors run so that you can focus on your business and the other important pieces that you have. I know we are almost to time, so I don’t think I think my demo takes a little bit more than six minutes, so I don’t want to push us on that. But like I mentioned at the beginning, I did want to throw out there that we’ve, you know, opened a community version or free version that includes service, mesh, so and custom system types. And so I encourage you all to take a look and peek around to see if that’s something that would work for your organization. If for nothing else, test it out and let us know. Good, bad, ugly, whatever that works for you. But there are no strings attached to it. We want folks to use it, and we want folks to use it in the capacity that they need it.