---
title: "Understanding security and access control requirements of microservices environment"
description: "Learn how you can implement robust security protocols and access control measures to ensure inter-services communicating is not compromised."
author: "Emre Baran"
date: "2025-06-11T10:46:02.827Z"
canonical: "https://www.cerbos.dev/blog/security-and-access-control-microservices"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Importance_of_Security_and_Access_Control_Protocols_in_Microservices_35ae6e2b13.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/security-and-access-control-microservices"
---

# Understanding security and access control requirements of microservices environment

[Watch on YouTube](https://www.youtube.com/watch?v=bMBdzKgDBV0)

Transitioning from a monolithic architecture to microservices is an intricate, time-consuming task. It demands both strategic foresight and meticulous execution.

In this 10-part series, we’ll guide you through the most common challenges faced during monolith to microservices migration. Last week we published the sixth part of our series, on the best practices for [testing and deploying microservices](https://www.cerbos.dev/blog/testing-and-deployment-strategies-microservices). This week, we are going to dive into security and access control in microservices.

We'll publish a new article every Monday, so stay tuned. You can also [download the full 10-part series](https://solutions.cerbos.dev/monolith-to-microservices-migration-ebook) to guide your monolith-to-microservices migration.

## Security in microservices brief intro

As your team decomposes your monolith over a distributed network of constantly communicating microservices, it creates an increased attack surface. If your security isn’t enhanced to deal with these new vulnerabilities, it leaves your system more exposed than if it was as a monolith.

That’s why it’s essential that your team understands the potential vulnerabilities of a microservices architecture and knows how to safeguard against them.

## Potential security vulnerabilities in microservice architectures

Flexibility is one of the benefits of using microservices. However, if not done correctly, this flexibility can result in inconsistencies which create vulnerabilities. There are four main aspects where these vulnerabilities show up.

![Potential security vulnerabilities in microservice architectures.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Potential_security_vulnerabilities_in_microservice_architectures_685de52031.png)

### Decentralized security

In a monolith architecture, all of the security-related logic resides inside the same project and codebase. In a microservice context, however, your security can’t be so simple. You will have to replicate and tailor your chosen security system to each service. If this isn’t done properly, it opens the door to security issues down the line.

### Token propagation 

A common authentication technique for microservices is token-based authentication, where a token is issued to a user or another service during authentication. Because they interact with a variety of databases and security systems, they are more susceptible to compromise.

### Security policies

Each microservice in your architecture has potentially been developed and maintained by different teams. If all teams are equally concerned with security, this isn’t a problem. However, if even one team is inconsistent in the implementation of security policies and controls, it creates a vulnerability that can be used to access the whole system.

### Service-to-service communication

Microservices are constantly communicating with each other. To keep this communication secure, your team needs to make sure that each microservice is authenticated and authorized when communicating with others. Improper authentication and authorization create vulnerabilities in your security that can be utilised to compromise the system.

_For a deep dive on authenticating and authorizing calls between services, check out our dedicated guide on [service-to-service authorization](https://www.cerbos.dev/blog/service-to-service-authorization)._

## Protecting your microservices architecture

There is no simple, band-aid solution that will secure every vulnerability listed above. However, by following best practices your team can design your microservices architecture to lower their impact on your microservices architecture. 

We’ll cover the four most important best practices below.

![Protecting your microservices architecture.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Protecting_your_microservices_architecture_b386a46fd1.png)

### Authentication and authorization

[Authentication](https://www.cerbos.dev/blog/authentication-vs-authorization) verifies the identity of a user or service, validating they are who they say they are. Authorization determines what actions or resources they are allowed to access. To ensure users and services are properly authenticated and only allowed to access the resources they’re authorized for, microservice architects often use token-based authentication mechanisms like JSON Web Tokens (JWT) or OAuth 2.0.

In token-based authentication, users/services are issued a token after they are successfully authenticated by the system. This token contains a variety of data, including the user’s identity and their permissions and is included in every request made by the user/service. This allows the receiving system to authenticate the user at each step and authorize (or deny) access to protected resources.

Spring Security, Microsoft Entra ID, and [Cerbos](https://cerbos.dev/) are all able to implement token-based authentication and authorization in your microservices architecture.

### Secure communication

Microservices are heavily reliant on communication across servers and storage types, so secure communication channels are essential for the integrity of your security system. Transport Layer Security (TLS) and mutual TLS (mTLS) are both effective ways to secure communication. They can (and should be) used in unison to maximise your security.

TLS encrypts communication channels to protect data from eavesdropping and tampering with authentication from the client. Mutual TLS authentication then adds an additional layer of security as it requires both the client and the server to authenticate each other.

### API Gateway and security

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. Besides limiting access to one portal, an API Gateway can also request authentication, validate tokens, control access and even provide rate limiting. It can also act as a reverse proxy, hiding the internal microservices architecture to provide an additional layer of security.

Kong, Apigee, and Amazon API Gateway can all be used to implement API Gateways in your microservices architecture.

### Zero Trust security

[Zero Trust](https://www.cerbos.dev/blog/zero-trust-authorization) is a security framework based on the principle "never trust; always verify". Services that use the system assume no implicit trust for any entity, whether inside or outside the network. Instead, it requires authentication and authorization with every request. 

When users/services are authenticated, access is only granted based on the principle of least privilege. That means users and services only have the necessary permissions to perform their tasks. This helps to minimize the impact of a potential security breach.

You can implement a Zero Trust framework using Mutual TLS (mTLS) for authentication, then layer in Cerbos for the [fine-grained authorization](https://www.cerbos.dev/blog/coarse-grained-vs-fine-grained-access-control), Role-Based Access Control [(RBAC)](https://www.cerbos.dev/blog/rbac-vs-abac), and Attribute-Based Access Control [(ABAC)](https://www.cerbos.dev/features-benefits-and-use-cases/abac) you’ll need to enforce access policies.

Though it can be quite complex, the tools/practices above can help you ensure your microservices architecture remains secure–which is exactly what Netflix did.

## The systems and tools Netflix used to ensure security in their microservices

When Netflix decomposed their monolith in favour of a microservices architecture (which we [covered in chapter 1](https://www.cerbos.dev/blog/determining-service-boundaries-and-decomposing-monolith)), ensuring the continued security of their app was absolutely essential. So, they adopted a Zero Trust security model and then implemented both in-house-developed and off-the-shelf software to ensure all traffic was authenticated and authorized properly. 

### Minimizing unwanted access with a zero-trust model

One of the biggest steps Netflix took to ensure security in their system was to embrace a zero-trust model. To enforce the principle of least privilege, they use mechanisms like Open Policy Agent (OPA) so they can define and enforce access policies at the microservice level. They also took a Role-Based Access Control approach to managing permissions and accessing rights. So each user and service is assigned specific roles, and access to resources is granted based on these roles. 

### Taking a closer look at authentication and authorization

Netflix chose to back up their zero-trust approach to authorization with a token-based system. They chose Stethoscope to handle user authentication and generate JSON Web Tokens (JWTs) containing both user identity and their permissions. 

### Clearing communication

Netflix needed to ensure the integrity of their data in transit, so they chose to use both TLS and mTLS. They use TLS to provide encryption for communication, while mTLS requires mutual authentication, ensuring that both the client and the server authenticate each other. 

### Developing an API Gateway and security

With a microservices architecture as large as Netflix’s traffic could become overly complex, making security difficult. To bring order to the chaos, Netflix developed an in-house API Gateway called Zuul, creating a single entry point for all client requests. Zuul handles authentication, rate limiting, and access control for the services, as well as performing request routing and load balancing, and distributing requests to the appropriate microservices.

### Good monkey

In addition to these security measures, Netflix decided to go above and beyond by automating continuous monitoring of their systems. They developed Security Monkey, an automated monitoring tool, to monitor and assess the security posture of their infrastructure without oversight. This constant vigilance identifies misconfigurations, policy violations, and potential security risks before they become problems, allowing Netflix to proactively address security issues.

Netflix addressed the vulnerabilities of a microservices architecture head-on with a comprehensive security architecture and Zero Trust principles. As a result, they have a secure microservices ecosystem that protects their user’s data.

## Looking ahead

Ready for the next in the series? Continue to [“How to build scalable and performant microservices”](https://www.cerbos.dev/blog/performance-and-scalability-microservices).

Or, you can [download the complete 10-part series in one e-book](https://solutions.cerbos.dev/monolith-to-microservices-migration-ebook) now: "Monolith to microservices migration: 10 critical challenges to consider"

Along with our e-book, consider a hands-on session. Book a [free workshop](https://www.cerbos.dev/workshop) with a Cerbos engineer to focus specifically on microservice access control for your stack.

> Our core guide on [microservice authorization.](https://www.cerbos.dev/blog/tips-for-microservices-authorization)

## FAQ

### What are common security issues in microservices architectures?

1. Decentralized Security Management: Each team or service might implement auth their own way, leading to inconsistent enforcement (some endpoints might lack proper checks). This is riskier than the monolith days when you had one place to handle auth.
2. Token Propagation Challenges: In microservices, you often pass along a user’s identity token from service to service. If not handled carefully, tokens can be intercepted or misused. Also, not propagating them means losing the user context, leading to services either giving too broad access or requiring re-auth, both problematic.
3. Excessive Trust (Lack of Zero Trust): Assuming an internal service call is safe because it’s from “inside” can lead to breaches. For example, if Service A trusts any request coming from Service B without verifying identity, an attacker who gains a foothold in B could pivot to A easily. Microservices should assume zero trust and verify every call.
4. Misconfigured Containers/Network: In microservices, you have many moving parts (containers, APIs). A common issue is misconfiguring network policies or container roles, accidentally leaving an internal API open to the world or giving a service more privileges than needed (like mounting host volumes it shouldn’t).
5. Difficulty in Visibility: With dozens of services, knowing who accessed what becomes harder. Logging needs to be centralized. A bug or attack might go unnoticed if each service logs separately and no one correlates them. Attackers exploit this to stay under the radar.

The article discusses many of these (like how failing to propagate auth tokens or inconsistent policy enforcement create vulnerabilities), and why a holistic approach is required.

### How is access control typically enforced in microservices?

There are a few layers to enforce access control. These include the API Gateway, Service-Level Checks, Sidecar or Middleware (for example with Cerbos), and Token/Identity Propagation.

In practice, a combination is used: gateway for broad strokes, in-service for specifics.

### What is token propagation and why is it important in microservices?

Token propagation means passing along the caller’s authentication token (or some representation of their identity/permissions) from one service to the next in a call chain. It’s important because without it, downstream services won’t know who the original user is or what they are allowed to do. They would either have to blindly trust the upstream service or attempt to re-authenticate the user (which is not feasible if the user isn’t directly interacting with them). 

Without token propagation, you risk either giving too much access (if downstream just trusts upstream’s request blindly) or breaking functionality (if downstream denies everything because it can’t authenticate the user). So it’s a cornerstone of secure microservice design.

### How can I ensure consistent security policies across many microservices?

**Centralization and automation** are your friends here. Some tips:

1. Use a Central Policy Store: Rather than each team writing their own rules scattered in code, maintain a central repository of authorization policies (like a Git repo with Cerbos policies) that cover all services. This way, policies are versioned, reviewed, and consistent. Cerbos, for example, lets you define all your service and user access rules in one place (Cerbos Hub or config repo) and deploy them uniformly.
2. Employ an Enforcer like a Service Mesh or Library: If every service uses the same library or sidecar for authZ, they inherently follow the same rules. For instance, if all services integrate with Cerbos PDP, then no matter who develops the service, they’ll use the same policy set. This removes individual interpretation differences.
3. Security Champions & Reviews: In an enterprise, designate a security-minded engineer in each team to ensure their service adheres to the common security guidelines. Also, before deploying new services or endpoints, have a checklist (does it enforce authZ? log access? etc.). Over time, this becomes culture.
4. Automated Tests/Scans: Create integration tests that run against every service’s endpoints with various roles to catch any endpoint that accidentally doesn’t enforce restrictions. Alternatively, in staging, run a “penetration test” where you attempt to access each service’s APIs with insufficient credentials to ensure they correctly deny access. Tools can automate checking RBAC enforcement if configured.
5. Monitoring & Alerts: Use centralized logging or tracing. If one service starts returning data for users that normally shouldn’t get it (maybe anomaly detection on access patterns), alert it. For example, if suddenly a service that should only be called by Service A is getting calls from Service X, flag that. This can catch misconfigurations or new services that deviate from policy.

By using shared infrastructure and vigilant governance, you ensure each microservice isn’t a law unto itself but part of a consistent security fabric. The effort to set this up is worthwhile – it prevents the “weakest link” scenario where one unsecured service can compromise the whole system.