How to Secure Microservices Without Creating a Distributed Nightmare | Cerbos

How to secure microservices without creating a distributed nightmare

AAnna PaykinaJune 14, 20267 min read

When your application is a monolith, security is relatively straightforward. Authentication happens in one place. Authorization logic lives in the same codebase. Network boundaries are clear. Then you decompose into microservices and suddenly every service is an attack surface, every service-to-service call needs to be authenticated and authorized, and every team is implementing security slightly differently.

The flexibility that makes microservices valuable is exactly what makes them harder to secure. If your security isn't enhanced to deal with these new vulnerabilities, your system is more exposed than it was as a monolith.

I've watched teams go through this transition dozens of times, and the pattern is consistent. They focus on getting the decomposition right, on data management, on communication patterns, and security becomes an afterthought. Then they spend the next two years cleaning up the mess.

Here's how to avoid that.

Where the vulnerabilities actually are

Before you can secure a microservices architecture, you need to understand where it's vulnerable. The OWASP Microservices Security Cheat Sheet is a good starting point, but there are four areas that consistently trip teams up in practice.

  1. Decentralized security logic: In a monolith, all security-related logic resides in the same project and codebase. In a microservices context, you have to replicate and tailor your security system to each service. Different teams implementing security differently creates vulnerabilities.

  2. Token propagation: Token-based authentication is the standard approach for microservices, but tokens are passed between services across different databases and security systems, making them susceptible to interception.

  3. Excessive trust between services: Many teams assume that internal service-to-service calls are inherently safe because they're behind the network perimeter. However, if an attacker compromises a single service, implicit trust allows them to access the entire system.

  4. Misconfigured containers and network policies: Centralized logging gaps make attacks harder to detect after the fact.

Five layers of microservices security

Securing microservices isn't a single solution. It's a set of overlapping layers that each address a different part of the problem.

Authentication and authorization

Authentication verifies identity, while authorization determines what that identity is allowed to do. These categories need to be handled at different levels in microservices. Token-based mechanisms like JSON Web Tokens (JWT) and OAuth 2.0 are the standard for authentication.

Authorization can be centralized to create more consistent security across services rather than scattering checks across each service.

Secure communication with TLS and mTLS

Microservices rely heavily on communication across servers and storage types, so secure communication channels are essential. Transport Layer Security (TLS) encrypts the communication channel, while Mutual TLS (mTLS) ensures both client and server authenticate each other.

API gateway as a security boundary

An API gateway limits routes into the system to give you more control over traffic. It can handle authentication, validate tokens, control access, and provide rate limiting. Tools like Kong, Apigee, and Amazon API Gateway can serve as an API gateway.

Zero Trust security

Zero Trust is a security model based on the principle of never trust, always verify. Authentication and authorization are required for every request, regardless of its origin.

Consistent policy enforcement across services

Keeping security controls consistent across all services is crucial. Implementing a central policy store helps in deploying uniform access controls.

How Netflix secured their microservices

Netflix embraced a Zero Trust model, enforcing the principle of least privilege. They centralized authentication into services running inside their API gateway to manage incoming tokens, verifying identity before generating an internal identity object called "Passport."

They also built Zuul, an open-source API gateway that centralizes many security functions. Secure communication channels with TLS and mTLS were implemented, along with automated monitoring to assess the security posture of their infrastructure.

Where Cerbos fits in

Cerbos addresses authorization specifically, acting as a centralized policy decision point for consistent, fine-grained access control across services.

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "review"
  rules:
    - actions: ["read"]
      effect: EFFECT_ALLOW
      roles:
        - "employee-service"

This policy can scale with additional attribute-based conditions for more contextual access decisions.

Getting started

Securing microservices requires addressing all five layers. If you're migrating from monoliths or enhancing security on your existing architecture, refer to: