How do you secure microservices?

You secure microservices by implementing overlapping security layers across your architecture. This includes token-based authentication with JWT or OAuth 2.0, fine-grained authorization enforced consistently across services, encrypted communication using TLS and mutual TLS, an API gateway as a controlled entry point, and Zero Trust principles that require verification for every request regardless of origin.

What are the biggest security risks in microservices?

The biggest security risks in microservices are decentralized security logic where different teams implement access controls inconsistently, token interception during service-to-service propagation, excessive implicit trust between internal services, and misconfigured containers or network policies. Any one of these can give an attacker a path from a single compromised service to the rest of the system.

How is microservices security different from monolith security?

Microservices security differs from monolith security because the attack surface is distributed. In a monolith, security logic resides in a single codebase with centralized access control. In microservices, each service must independently handle authentication and authorization, communication must be encrypted between services, and policies need to be enforced consistently across teams and codebases that may evolve at different speeds.

What is Zero Trust in a microservices architecture?

Zero Trust in a microservices architecture means that no service is inherently trusted, regardless of whether it sits inside the network perimeter. Every request between services requires authentication and authorization. Access is granted based on the principle of least privilege, so services only get the permissions needed to perform their specific tasks. This limits the blast radius if any single service is compromised.

How do you keep authorization consistent across microservices?

You keep authorization consistent across microservices by centralizing your access control policies rather than scattering authorization logic across individual services. A centralized policy decision point evaluates every access request against the same set of rules, regardless of which service is asking. Cerbos provides this by letting teams define policies in version-controlled YAML and enforce them uniformly across all services at runtime.

What role does an API gateway play in microservices security?

An API gateway plays the role of a security boundary in microservices by acting as the single entry point for all external client requests. It handles authentication, token validation, rate limiting, and access control before traffic reaches individual services. It also serves as a reverse proxy, hiding the internal architecture from external callers and reducing the number of exposed endpoints that could be targeted by attackers.

How to Secure Microservices Without Creating a Distributed Nightmare

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

vulnerabilities microservices monoliths.png

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.

Decentralized security logic is the most common problem. 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. When different teams implement security differently, with different levels of rigor, the weakest link becomes the entry point for an attacker. If even one team is inconsistent in their implementation of security policies and controls, it creates a vulnerability that can be used to access the whole system.

Token propagation introduces its own risks. Token-based authentication is the standard approach for microservices, but tokens are passed between services across different databases and security systems, making them more susceptible to interception and misuse. Without proper safeguards, a compromised token gives an attacker authenticated access to downstream services that trust it.

Excessive trust between services is the zero trust gap. Many teams assume that internal service-to-service calls are inherently safe because they're behind the network perimeter. They're not. If an attacker compromises a single service, implicit trust lets them move laterally across your entire system.

Misconfigured containers and network policies round out the picture. Container orchestration adds its own security surface, and 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. Get one wrong and the others can't fully compensate.

Authentication and authorization

Authentication verifies identity. Authorization determines what that identity is allowed to do. These are different concerns, and in microservices they need to be handled at different levels.

For authentication, token-based mechanisms like JSON Web Tokens (JWT) and OAuth 2.0 are the standard. After a user or service is successfully authenticated, the system issues a token containing identity and permissions data. This token is included in every subsequent request, allowing the receiving service to verify the caller's identity at each step.

Authorization is where most teams struggle. In a monolith, a single authorization check can gate access across the entire application. In microservices, each service needs to make its own authorization decisions, and those decisions need to be consistent. If your payments service enforces one set of access rules and your user service enforces another, you've got a gap.

This is where centralizing authorization logic matters. Rather than scattering if statements across every service, you define access policies in one place and evaluate them at runtime. Every service asks the same policy engine the same question, and gets a consistent answer.

Secure communication with TLS and mTLS

key features of a service mesh.png

Microservices rely heavily on communication across servers and storage types, so secure communication channels are essential. Transport Layer Security (TLS) encrypts the communication channel to protect data from eavesdropping and tampering. Mutual TLS (mTLS) adds an additional layer by requiring both the client and the server to authenticate each other.

Used together, they maximize security for service-to-service communication. TLS ensures nobody can read the data in transit. mTLS ensures both sides of the conversation are who they claim to be.

API gateway as a security boundary

An API gateway acts as a single access point for external clients, limiting the routes into the system to give you more control over your traffic. Beyond routing, an API gateway can handle authentication, validate tokens, control access, and provide rate limiting. It can also act as a reverse proxy, hiding the internal microservices architecture from external callers.

Tools like Kong, Apigee, and Amazon API Gateway can all serve this function. The key is that the gateway becomes your first line of defense, handling the security concerns that apply to all inbound traffic before requests reach individual services.

Zero Trust security

Zero Trust is a security framework based on the principle of never trust, always verify. Defined formally in NIST SP 800-207, it assumes no implicit trust for any entity, whether inside or outside the network. Every request requires authentication and authorization regardless of where it originates.

When users and services are authenticated, access is only granted based on the principle of least privilege. Users and services only get the permissions they need to perform their tasks. This minimizes the blast radius of a potential breach.

You can implement Zero Trust using mutual TLS for authentication, then layer in fine-grained authorization for the access control decisions. Workload identity frameworks like SPIFFE provide cryptographic identities for services, eliminating reliance on network location as a trust signal. The combination of verifiable identity at the transport layer and policy-based authorization at the application layer gives you defense in depth.

Consistent policy enforcement across services

The hardest part of microservices security isn't implementing any single control. It's keeping them consistent across all your services.

When different teams build different services, each with their own approach to access control, inconsistencies creep in. A central policy store with version-controlled authorization policies deployed uniformly across services solves this. Shared enforcement through common libraries or sidecar proxies ensures that every service applies the same rules. And automated testing that verifies endpoint restrictions across all services catches regressions before they reach production.

How Netflix secured their microservices

When Netflix decomposed their monolith, ensuring continued security was essential. Their approach is worth studying because they addressed every layer systematically.

They embraced a Zero Trust model, enforcing the principle of least privilege at the microservice level with role-based access control. Each user and service was assigned specific roles, and access to resources was granted based on those roles.

For authentication, Netflix moved identity verification to the edge of their network. As described in their Edge Authentication and Token-Agnostic Identity Propagation engineering blog post, they centralized authentication into a set of services running inside their API gateway. This edge authentication system processes incoming tokens, verifies identity, and generates an internal identity object called "Passport" that propagates through downstream services. By centralizing authentication at the edge, they eliminated the need for individual services to understand the complexity of different authentication protocols.

Netflix also built Zuul, an open source API gateway that creates a single entry point for all client requests. Zuul handles authentication, rate limiting, and access control, as well as request routing and load balancing. The edge authentication system runs as a series of filters within Zuul, inspecting tokens on every inbound request.

They secured communication channels with both TLS and mTLS, ensuring data integrity and mutual authentication for all service-to-service calls. And they developed Security Monkey (which has since been retired), an automated monitoring tool that continuously assessed the security posture of their infrastructure, identifying misconfigurations and policy violations before they became problems.

Where Cerbos fits in

Cerbos addresses the authorization layer specifically. It acts as a centralized policy decision point that every service can call to get consistent, fine-grained access control decisions.

Here's a policy from our Zero Trust for microservices guide that controls what a service can access based on its workload identity.

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

This is a simple example, but the pattern scales. You can layer in attribute-based conditions so that access decisions consider context like department, environment, or the relationship between the caller and the resource being accessed.

For on-behalf-of scenarios, where one service is acting on behalf of a user via an act claim, Cerbos can evaluate both the service identity and the user identity in the same policy check.

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "review"
  rules:
    - actions: ["read"]
      effect: EFFECT_ALLOW
      derivedRoles:
        - manager_in_department
      condition:
        match:
          expr: "request.principal.attr.act.user.attr.department == request.resource.attr.department"
    - actions: ["read"]
      effect: EFFECT_ALLOW
      derivedRoles:
        - hr_user

The policies are YAML-based and version-controlled alongside your code. They're evaluated at runtime with sub-millisecond latency, and every decision is logged for audit. This means you get consistent authorization across all your services, regardless of which team built them or what language they're written in.

Getting started

Securing microservices well means addressing all five layers, not just the one that feels most urgent. Authentication, authorization, secure communication, API gateway controls, and Zero Trust principles each solve a different part of the problem.

If you're in the middle of a monolith-to-microservices migration or looking to tighten security on an existing architecture, here are two places to go deeper:

Our monolith-to-microservices migration ebook covers security as one of ten critical challenges, including practical guidance for each stage of the transition.
For a detailed look at Zero Trust patterns with code examples and workload identity strategies, see our Zero Trust for microservices blueprint.