Why Microservices Require Unified Tools for Authorization

Cloud-native organizations embracing microservices are running into an unavoidable security question: how to handle microservice authorization controls? 

The central problem is this: unlike monolithic app structures, microservices architectures expose dozens more functionality through APIs, which can leave them vulnerable to attack. If an attacker were to compromise one server in an application, in other words, they could call an APIs as if it were part of the application itself—granting the attacker further access to other functions and data. The solution for these companies is for their microservices teams to secure these internal APIs. 

That’s part of the problem: practically speaking, this means that development teams need to enforce API authorization not only at the gateway, but also at the microservice level. This would be simple enough, if the problem needed to be solved for a single microservice.

However, there is the entire enterprise to consider—and the frequent outcome is that application development teams hardcode the authorization policy for each individual microservice within every application. Far from a neat, harmonious collection, these authorization policies come to represent an unholy mishmash of different coding assumptions, logics, configurations, limitations and, most confounding of all, coding languages.

While one dev group writes in Java, the others prefer C, or Ruby, or Rust, and so on. Companies end up with a mosaic of different ways to implement authorization policy and logic that are hard to manage, hard to analyze for compliance and security and hardest of all to scale. 

To solve this problem, organizations need unified tools—and a unified language—to implement and manage authorization policy across their microservices architectures. The first step in this process is, rather than hardcoding policy directly, to decouple authorization policy from the microservice itself. Then, to maintain the same performance and availability as if the policy were implemented inside the microservice, it is necessary to have the policy run as a kind of sidecar next to the microservice—or at least on the same server. This ensures that the microservice can retrieve an authorization decision quickly, even when the network is log-jammed.

In general, organizations need to find unified tools that let them implement distributed authorization policies, throughout the microservice application architecture, in a centralized way. 

 

You can read the rest of this article on Infosecurity Magazine. 

Request a demo to learn more about authorization for microservices here.  

 Prev

Five OPA and Styra Trends that Prove Kubernetes Adoption

Next  

API Authorization at the Gateway with Apigee, Okta and OPA (Part 1)

Subscribe

API Authorization at the Gateway with Apigee, Okta and OPA (Part 1)

API gateways have become a standard..

September 24
Go

Five OPA and Styra Trends that Prove Kubernetes Adoption

I’m often asked from people outside the..

August 27
Go