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.
The Three Reasons to Adopt a Unified Microservice Authorization Strategy
The goal of having unified authorization tools to create a seamless, end-to-end way to manage microservice authorization. Rather than have 10 or 50 different implementations that achieve similar goals, you have one common language to implement and share that logic with microservice teams across the enterprise.
There are a number of reasons why enterprises should consider adopting such tools. For one, application teams, rather than reinvent the authorization wheel, can spend more time on application development cycles and solving the business problems the app was built to address. Moreover, there are substantial security and compliance benefits that come with a unified approach to microservice authorization:
1. Security, app and enterprise-wide. Authorization policies are not only enforced at the gateway; they are enforced throughout the entire microservice application. This means that attackers, even if they compromise part of an app, never have unmitigated access to the APIs for the remaining parts of the app. Each API call is authenticated and authorized, and every API is protected the same way — meaning any attempt at lateral movement by an attacker is severely limited.
2. Simplified management. Rather than having policies written in Ruby, Rust, and Java, each with different logics, unified tools give you unified authorization policies written in one common declarative language, housed in separate, dedicated files. This simplifies policy management and analysis substantially. For example, security or compliance teams easily answer questions like, “Can a contractor access any APIs that return protected information?” Because policy is centralized, and, because there are naturally fewer files, it becomes substantially simpler to understand what the policies are and how the policy files work.
3. Intrusion detection and response. Because authorization policies are decoupled from the underlying services, if a node appears compromised the policies can be updated on the fly to limit the functionality that node has access to. Consistent authorization also leads to consistent logging, enabling more accurate SIEM rules to detect aberrant behaviors and therefore intrusions in the first place.
Consistent authorization policies
The benefits of microservices architectures are substantial. Yet, their authorization challenges can’t be wished away. Every organization that’s embracing microservices and moving to containerized applications hosted on platforms like Kubernetes needs to put guardrails in place to ensure that authorization policies are properly configured for security and compliance.
By moving to a unified policy language and adopting unified authorization toolsets, however, companies can ensure that they have a consistent means by which to create, manage and analyze policies — saving time, enabling collaboration, improving security and compliance and enabling dev teams to spend more time solving business problems.