Microservices Authorization: Styra DAS moves up the stack

We’ve had an exciting past six months at Styra, from a Series A funding announcement to tremendous growth in the Open Policy Agent (OPA) community to new enhancements to our commercial product, Styra’s Declarative Authorization Service (DAS). All of this great momentum maps to our overarching vision of unifying authorization and policy for the cloud-native environment. So, I’m happy to announce we’ve reached another milestone in our vision by adding support for microservice authorization to Styra DAS.  

When we founded OPA, we designed it for portability so that OPA could be used to solve authorization (and more generally policy) problems across all of the most critical cloud-native components. We built the Styra DAS to be a general-purpose, enterprise-grade OPA control plane that helps enterprises deploy OPA in production, at scale. We first launched the Styra DAS in 2019 with special support for Kubernetes because it was the most popular use case in the OPA community.  

When an enterprise embraces Kubernetes as a platform, they need to ensure that K8s clusters are secure, performant and tick all the right compliance check boxes. Those organizations also have to ensure that when their developers run applications on top of Kubernetes that they don’t accidentally misconfigure their apps or clusters in dangerous ways or make mistakes that could lead to security, operational or compliance risk. The DAS helps enterprises set up policy-as-code guardrails for Kubernetes, ensuring that workloads are configured according to the internal and external policies designed to prevent common missteps and errors and in so doing mitigate all these kinds of risks.

It’s important to remember that when a company embraces Kubernetes, it’s not for Kubernetes itself, but rather because Kubernetes is the best way to run containerized applications. The app—not the platform it runs on—is the end goal. And just like it’s critical to define and enforce policy at the platform level, it’s also critical to define and enforce policy at the app level.   

To illustrate this, here are a couple examples we’ve seen in one form or another: 

While solving these types of problems for a single microservice is fairly straightforward, an organization-wide solution across services becomes much more challenging due to the large number of constantly changing teams, each of which are: using different languages, solving different problems, releasing code through different CICD pipelines, and overall building and maintaining hundreds or thousands of microservices.

Despite the fact that K8s and microservices are different levels of the proverbial app stack, they both need authorization policies enforced, and any organization embracing microservices will need to solve this problem. To paraphrase Netflix, one of the earliest adopters of OPA, this isn’t a problem you can wish away. 

One of the keys to solving the microservice authorization problem at scale is to use OPA to decouple policy from the microservices that enforce it. Before OPA, each different development team had to implement their own different authorization policy within their own custom applications. So if you had one team using java, they’d write their authorization policy in java code. If you had another team using ruby, they’d write their authorization policy in ruby code. So, at the end of the day, you’d end up with numerous different ways of implementing authorization logic / authorization policy – which makes testing nearly impossible, makes collaboration across teams extremely difficult, adds complexity for updates, and often means personnel changes result in lost “tribal knowledge” that requires a redevelopment or reinvention of undifferentiated work.  (Not to mention a lot of compliance headaches!). 

Now, with OPA you can decouple those policies— separate the authorization policies from the individual services. Instead of having 10 to 50 different implementations of similar logic, you have one way – one tool set of implementing that logic that works across all the different service teams, and all their custom apps, and even the infrastructure that runs those apps. Styra DAS provides the authoring, distribution, impact analysis, monitoring and audit controls for those decoupled policies. So, policy can be consistently defined in a single language, and deployed with a single control plane across today’s software-defined infrastructure, and the apps that run within it.

The technology and architectural decisions that have been embraced by K8s and the microservice architecture make this unification of policy incredibly practical and incredibly timely. I see this new extension of Styra DAS as effectively delivering on the next step of our vision of unified policy across the entire cloud native stack.

With this new support for microservices authz, developers no longer have to reinvent the wheel each time they implement a policy system within their application. Now, they can spend more time and more development cycles on the crucial business problems that their application was designed to solve. With support for microservices, Styra DAS further helps teams save time and effort, and accelerate application time to market, without security, operational or compliance risk.  

Excited to learn more? Check out our support for microservices page!