Using OPA for cloud-native app authorization

In the cloud-native space, microservice architectures and containers are reshaping the way that enterprises build and deploy applications. They function, in a word, differently than traditional monolithic applications.

Microservices are far more distributed and dynamic than their traditional counterparts. A single application might have tens or hundreds of microservices, leading potentially to thousands of separate OS-level processes, each with its own API, deployed across multiple data centers all over the world, and spun up and down dynamically. These architectural differences from monolithic applications cause challenges for developers, operations, and security alike.

Among the biggest security challenges is authorization: controlling what users and machines can and can’t do within the application. In the pre-cloud era, authorization was solved at the gateway level—at the point at which end-users interacted with the application’s API—and often the downstream requests were assumed to be authorized.

For a microservice application running in the cloud, gateway-level authorization is far less secure. If an attacker compromises a single microservice component, they can run the APIs of all the microservices that make up that application, which gives them complete control over it and all of the data it protects. So while internal APIs and microservice architecture enable better time-to-market for the application, they also pose a substantial security risk and need to be protected by deploying authentication and authorization, just like for public APIs.

Changing development strategy

Not only are the architectural changes brought about by microservices substantial, but the way people develop microservice-based applications is changing radically too. Traditionally, companies had a few highly coordinated development teams who built the application in tandem, and who released software only after intense scrutiny. Today, numerous dev teams work independently on discrete, individual application components, and they release code whenever they see fit. No team is responsible for “the whole app.” The benefit of having numerous teams is that they can all work independently, and therefore deliver software more efficiently overall.

However, having numerous teams also means that every team needs to maintain and enforce authorization policies for each of the services they are responsible for. The real challenge is that security, compliance, and operational teams also need to understand these authorization policies; they’re responsible for them. And if you ask 10 teams to implement authorization for their service, you’ll end up with 10 different hardcoded implementations in different programming languages, with different enforcement guarantees and different ways of logging unauthorized access attempts.

Copyright © 2020 IDG Communications, Inc.

Source link