Microauthorization: Why Microservices can be Great for Security Hygiene

Unless you have been living under a rock, you have probably heard the “microservices” buzzword where folks decompose large applications (aka monoliths) into a number of smaller services that talk to one another via APIs. The key motivation that most folks talk about with microservices is the ability to independently roll out each service (subject to API versioning best practices) and how that enables teams to move faster. However, there is another benefit of properly decomposing monoliths into micro services, which I do not think we talk about enough: security.

When you run your application as a monolith, all of the application code generally runs in the same process, so there is zero meaningful isolation across different parts of the application. As a result, most users tend to use a single monolithic identity for the monolithic workload, which,even following least privilege, possesses the union of all of the capabilities needed for all of the different functions of the application; it is effectively a super-user identity (a great target for credential exfiltration, with a large blast radius).

By segmenting applications into microservices, you start to run the parts of your application in different process spaces, and it becomes practical to present each microservice with a distinct identity. This identity segmentation means that each microservice can receive an Identity and Access Management (IAM) grant with fewer capabilities than it would have had in the context of the monolith. It means that as one piece of the logical application needs an additional capability, you can grant it to only the application code living in the microservice that needs it, instead of exposing that capability to all of the application code.

Consider a remote code execution (RCE) vulnerability in the monolith: the attacker is able to wield the full capabilities of your entire application through a single breach.

Consider the same in a well-conceived microservices architecture: the attacker has to figure out how to move laterally from the compromised publicly-exposed service into other services (possibly not exposed externally) in order to reach credentials with the capabilities they may need to achieve their goal. If your architecture leverages service-to-service authorization, then this might require the attacker to make multiple hops before they reach a service with elevated credentials.

You might be thinking: But containers don’t contain! That’s true, and if you are running microservices on a multi-tenant cluster then there are other potential lateral movement paths. But once you have achieved this segmentation you can start to leverage stronger sandboxing for harder multi-tenancy or run your services on Container-as-a-Service platforms that are designed for this type of strong isolation (e.g. AWS ECS, AWS Lambda, Google Cloud Run, etc).

One of the ways I think about this is that each time you invoke a piece of application logic that needs elevated capabilities it is like invoking sudo for those capabilities. Just as you should strive to minimize the scope you wrap in sudo, so too should you strive to minimize the scope of application logic that is exposed to elevated capabilities.

In short, microservices can actually enhance security. If you are interested in learning more about this topic, please reach out.