Friday, August 19, 2022
HomeCloud ComputingLearnings from Implementing Microservices Authorization

Learnings from Implementing Microservices Authorization


As soon as builders begin the journey of adopting a contemporary microservices based mostly structure additionally they must deal with different facets of Cloud Native structure like Full Stack Observability, microservices authentication and authorization, CICD pipeline and so on. Cisco’s DevRel engineering group has been growing all its purposes as microservices, and operating these on a Kubernetes based mostly Cloud Native platform for five+ years. As an early adopter of Cloud Native structure, the DevRel engineering group must develop and evolve numerous core platform capabilities like microservice authorization.  

Our microservice authorization framework has gone by architectural replace 3 instances as Cloud Native ecosystems have advanced. Once we’d hit an architectural limitation with an previous sample, we discovered and improved the profit with a brand new sample. In case your group is beginning new on Microservices you can begin straight with adopting commonplace tooling like Open Coverage Agent (ref opa_styra, coverage as code, istio-k8s-opa ). Nonetheless, in case you are inquisitive about studying different microservices authorization patterns and study challenges and advantages of every, then proceed studying.  

What’s microservice authorization?

Because the variety of Microservices deployed in any surroundings grows there arises want to manage which customers and microservices can entry which microservices with wonderful grained entry management for particular person API (Functions Programming Interfaces) endpoints. Entry management system consists of details about sources which are protected like API endpoints URL, topic requesting entry that may be person or one other service making service-service API name, insurance policies that permit or deny entry together with different contextual data.  

Authorization methods sometimes contain Coverage Choice Level (PDP) to judge coverage & make choice, a Coverage Enforcement Level (PEP) to implementing entry management and Coverage Data Level (PIP) that provides added data/context required by PDP to make choice. Refer NIST ABAC coverage paper for extra data. 

Easy instance authorization coverage of one in every of Course Administration microservices the place admin person for course administration and DevNet is given entry to create new course. As well as, PubHub content material publishing microservice can also be given write entry to make service to service name.  

microservices authorization

Now allow us to have a look at microservices Authorization architectural patterns evolution for DevRel Engineering group.

  1. Authorization implementation by Every Microservices
  2. Authorization implementation through centralized API Gateway
  3. Authorization implementation by microservices Facet Vehicles in Istio Service Mesh

microservices authorization

Authorization implementation by every microservices

For first iteration authorization is applied by every microservices, this requires code to be included by every microservices code. To keep away from code duplication it was applied as Golang middleware for http REST APIs. Each API request made to service from finish person or different microservice is first evaluated by go authorization middleware and request is handed to microservice implementation solely when entry is allowed by authorization coverage. However this strategy had few limitations:

  • Coverage guidelines should be maintained by every microservice improvement group and altering coverage management code required rebuilding all microservices.
  • Updating coverage requires redeployment of microservice even insurance policies are externalized as Kubernetes deployment config.
  • Tough to fulfill infosec necessities for centrally controlling and auditing coverage modifications.

Authorization implementation through centralized API gateway

For second strategy DevRel engineering group moved go middleware logic to separate ABAC microservices, additionally construct UI to ease of coverage administration. This allowed authorization insurance policies for all microservices to be maintained centrally following central PDP and PIP precept. Coverage enforcement (PIP) is applied in Nginx API gateway utilizing customized LUA plugin that interacts with ABAC service to make entry coverage choice for every API name by finish customers. This strategy helped resolved limitation of first strategy however this implementation has one key limitation:

  • API gateway solely gives entry management just for exterior person generated API calls, for inside service-service API gateway is often not concerned. To allow service-service authorization we left minimal go middleware authorization module as go middleware.

Authorization implementation by microservices facet vehicles in Istio Service Mesh

As we began to judge and undertake Istio service mesh in our Kubernetes Cloud Native platform that host all our microservices group realized that customized Nginx entry management plugin will be simply migrated to Envoy proxy sidecar exterior authorization plugin.  Distributed coverage enforcement factors by sidecar supplied a number of advantages

  • All API name irrespective it’s from exterior person or from inside service-service are persistently enforced by facet vehicles appearing as Coverage enforcement level (PEP).
  • All insurance policies are centrally managed and audited as per infosec requirement in ABAC management microservice appearing as Coverage choice level and Coverage data level.
  • Despite the fact that insurance policies are enforced at every microservices degree particular person providers developer don’t want so as to add any code or coverage config, authorization is seamless for service developer.

Because the DevRel group advanced an authorization framework based mostly on self-learning and evolution of Cloud Native ecosystem, it appears our customized answer has resulted in a really related architectural sample to that of OPA Envoy proxy authorization. DevRel engineering group as an early adaptor of know-how needed to implement customized authorization answer however for builders now beginning their microservices journey can begin with evaluating OPA plugin. Tell us if you want to study extra about it. Or, in case you are already implementing micorservice authorization, then please share how your group is implementing it.


We’d love to listen to what you suppose. Ask a query or depart a remark under.
And keep related with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Fb | Developer Video Channel




Most Popular

Recent Comments