Application Security

Microservices Authorization using Open Policy Agent and Traefik (API Gateway)

Application Security
Apr 7, 2020
4 min read
Abhishek Datta
The need for Centralized Authorization Controls

Authentication and authorization in a microservices environment is non-trivial to implement correctly. This becomes especially true when identity and authorization controls are distributed across different applications. There has been multiple cases where authorization controls implemented for one application was missed for another application with similar feature and data access resulting in a breach.

One of our clients had similar requirements in their SaaS platform where they needed to call multiple APIs from a single frontend using ID Token. The ID Token was obtained using a conventional OAuth2 Authorization Code flow from an external provider such as Auth0. While OpenID Connect serves as an excellent standard for sharing verifiable user identity across microservices, we did not find a standard approach for enforcing authorization controls before a request hits a backend microservice.

Exposing microservices through an API Gateway

Additionally, we wanted to ensure that the ID Token is verified and authorization controls are enforced in the API Gateway itself before the request reaches a backend service. This allows us to create an architecture where authentication and authorization controls are enforced as a security gate for all backend microservices.

We present a solution along with a proof of concept implementation for the problem described above — To be able to perform authentication and authorization for microservices in the API Gateway itself.

A complete proof of concept implementation for the solution presented in this article is available in our Github repository.

How we chose to implement centralized AuthN and AuthZ controls using API Gateway

To implement our requirements, we need two things

  1. An API Gateway capable for integration with external system for policy decision making
  2. A policy repository and evaluation server which can authorize a given request (context) against configured policies

We have been hearing great things about Open Policy Agent (OPA) for quite some time. While choosing OPA for [1] may be a no brainer for some, we selected it for our use-case due to

  1. Support for Policy as Code
  2. Ability to run as server or as an embedded library
  3. Context-aware policy evaluation

The Open Policy Agent (OPA, pronounced “oh-pa”) is an open source, general-purpose policy engine that unifies policy enforcement across the stack.

We then looked at OPA Ecosystem for [1] API Gateway. We end up choosing Traefik as our choice for API Gateway due to

  1. Easy to learn and adopt
  2. Support for custom middlewares (3rd party service integration)
  3. Awesome dashboard :)
  4. Native support for automatic service discovery for Kubernetes
  5. Native support for exporting metrics to Prometheus

Our final architecture involving Traefik as the API Gateway and Open Policy Agent as the authorization server is presented below

Solution architecture for AuthZ using Traefik and Open Policy Agent
Using Traefik Middlewares for Integrating Open Policy Agent

Traefik supports middleware for transforming or validating a request before it is forwarded to a backend service. Among them, the ForwardAuth middleware is particularly interesting for us as it delegates decision making to an external application.

We implemented a simple NodeJS ForwardAuth Middleware application to connect Traefik with Open Policy Agent. Our middleware application builds an input context based on request parameters and passes it to Open Policy Agent for evaluation & decision making.

Implementing Authorization Controls in Open Policy Agent

Our use-case depends on Open Policy Agent (OPA) for the following

  1. Write policy rules using a formal policy language — Rego
  2. Run OPA as a context-aware policy evaluation server

For this use-case, we define a simple policy that authorizes requests based on path based microservice routing and role definition in JWT provided by the client.

Refer to the proof of concept implementation for all technical details.

The outcome is all requests passing through Traefik is authorized by our policy in OPA. We have our API Gateway act as a security gate for the microservices infrastructure.

Summarizing the Solution
  • We want to implement authentication and authorization for all microservices in a centralized manner
  • We want to enforce authentication and authorization in the API Gateway as a security gate

We achieve this by

  1. Using Traefik as the API Gateway
  2. Using Traefik ForwardAuth Middleware to delegate security policy enforcement to Open Policy Agent
  3. OPA policy in Rego language to enforce role based access control for backend microservices
Solution in Action

Special thanks to Etermax Engineering blog for writing about their use-case.

Hire Appsecco to help you secure your microservices infrastructure
At Appsecco we provide advice, testing and training around software, infra, web and mobile apps, especially that are cloud hosted. We also specialise in auditing complex cloud native microservices infrastructure and help product teams secure the same by assisting with threat modelling and security architecture review.
Drop us an email, contact@appsecco.com if you would like us to assess the security of your microservices infrastructure or if you would like your product team to be trained in implementing security controls for microservices.

HAZE WEBFLOW TEMPLATE

Build a website that actually performs better.

1
Lorem ipsum dolor sit amet consectutar
2
Lorem ipsum dolor sit amet consectutar
3
Lorem ipsum dolor sit amet consectutar