Ensure applications, services, and infrastructure are configured properly for security, compliance, and operations.
Businesses leveraging cloud-native tools to power digital transformation are running headlong into security questions concerning microservice authorization controls.
The core issue is that a microservice architecture exposes 10 or maybe even 100 times more functionality through APIs than in a monolithic architecture. An attacker that compromises one server in an application can now invoke those APIs as if they were part of the application itself. That is, of course, unless the microservice teams secure those internal APIs.
More concretely, this means that in addition to enforcing API authorization at the gateway, teams need to enforce API authorization at the microservice level. This often results in each application development team hardcoding the authorization policy for each microservice within the microservice itself. Those authorization policies end up having different organization, assumptions, limitations, defaults, configuration and are certainly written in different languages—one group is writing in Java, while another relies on Ruby, or Rust, or C, etc. You end up with a patchwork quilt of tools for authorization logic/policy that is hard to manage, hard to understand and analyze for security and compliance, and harder to scale.
Fortunately, the open-source Open Policy Agent (OPA) project provides a unified way of implementing microservice authorization across all languages, architectures, and applications. At the last KubeCon (in San Diego in November), we heard how Atlassian, Pinterest, and Yelp have all embraced OPA as a unified solution to microservice authorization, just like Netflix had several years ago in Austin.
One key challenge for microservice authorization is that while it is valuable to decouple the authorization policy so it is not hardcoded into the microservice itself, we still need roughly the same availability and performance for the microservice to retrieve authorization decisions as if the policy were implemented inside the microservice. To solve this problem, OPA runs as a sidecar next to—or at least on the same server as—the microservice that needs the authorization decision. This ensures the microservice retrieves an authorization decision rapidly even in the face of networking problems, but still achieves the goal of decoupling the policy from the microservice.
Architecturally you can think of OPA as the data plane for authorization. It is the software component that makes on-demand decisions and is distributed throughout the microservice application architecture. Because there are many instances of OPA you need a way to manage or control all of them, which is where Styra Declarative Authorization Service (DAS) steps in. DAS provides a uniform control plane for all of the OPAs, the policies they are enforcing, and the decisions they are making.
Benefits of Unified Microservice Authorization
The combination of OPA and Styra DAS provide an end-to-end, unified solution to microservice authorization. Instead of having 10 or 50 different implementations of similar logic, you have one common language to implement and share that logic across all the microservice teams.
Saving application teams from reinventing the wheel when it comes to authorization means they can spend more development cycles on business problems. Additionally, security and compliance benefit substantially from a unified solution to microservice authorization, in at least the following ways.
Security in-depth. Authorization policies are not simply enforced at the gateway. They are enforced throughout the entire microservice application. That means if an attacker has compromised some part of an application, they don’t have unfettered access to the APIs for the remaining components of the app. Every API, whether internal or external, is protected the same way. Each API call needs to be authenticated and authorized, meaning any attempt by an attacker to move laterally is severely limited.
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.
Analyzability. Instead of having policies written in Java, Ruby, Rust, etc. and intermingled with business logic, you end up with all those authorization policies written in one common declarative language in separate, dedicated files. This simplifies policy management and analysis substantially. For example, security or compliance teams can ask questions such as, “Can a contractor access any APIs that are known to return PII data?” That’s possible because the policy is centralized and, naturally, there are fewer policy files, and they are all written in the same language so it is clear how the policy files work.
Unified authorization across the stack
While the benefits of unified microservice authorization are substantial, OPA and Styra DAS provide unified authorization across more than just microservices. The platform that those applications run on is quite often Kubernetes, which has its own unique needs for authorization that OPA and the DAS are uniquely well-suited to solve. Every organization embracing Kubernetes for production should be putting guardrails in place that ensure the applications and the services and infrastructure they depend on are configured properly for security, compliance, and operations. That kind of authorization (or more technically admission) control is another example of where unified authorization provides organizations with numerous benefits. The fact that OPA and Styra’s DAS provide unified authorization across both the platform and the app amplifies the benefits of both to the organization as a whole.