All Articles

Security for microservices

This summary was done using my notes from this below brilliant article:

Chanaka Fernando (2021), How to implement security for microservices, Medium.

Securing microservices

In a distributed system, we can identify 2 levels of security that need to be implemented:

  1. Control access from external consumers
  2. Control access for internal services

Securing external consumers

Most of the enterprises focus more on securing the microservices from external consumers since that is the more vulnerable path. 3 approaches are common to implement security at this level:

  1. Implement security at each microservice level
  2. Implement security using a sidecar
  3. Implement security using a shared gateway

Security at each microservice level

Individual microservices implement security for each service. It is important to adhere to a common security standard such as OAuth 2.0 when implementing security since that would make the life of the clients a lot easier.

Clients will communicate with these services using a common approach (JWT token or opaque token) and a common Identity Provider (IDP) is used to validate the security credentials presented by the clients. If the token type is a self-contained JWT token, microservices will validate the token by itself without contacting the IDP.

Pros: teams decide on the best technology to implement security. Cons: each team is spending time on implementing the same functionality.

Security using a sidecar

We use an external framework such as Istio or Open Policy Agent (OPA) to implement the security for each microservice and this security component (agent) runs alongside the microservice as a sidecar.

The security functionality is handled through an external component (sidecar) which can be configured independently from the microservice itself.


  • change security configurations without changing the source code of the microservice.
  • keeps the overall architecture as independent and microservices friendly as possible.

Security using a shared gateway

An API gateway or a security gateway sits in front of the microservices layer. Every call to the microservice will go through this component and be validated for the credentials before reaching out to the microservice.

The API gateway will communicate with the IDP to validate the credentials of the client based on the token or authentication approach used to implement security.

Pros: microservices need not be touched if you need to change the security configurations. Cons: it introduces a monolithic component to the overall architecture.

Securing communication between microservices

3 approaches are common to implement security at this level: 1.Transport layer security

  1. Transport layer security with message layer security using authentication
  2. Transport layer security with message layer security using authentication and authorization

Transport layer security

This is the least secure approach with SSL enabled for communications between the microservice and a messaging platform (e.g Kafka). Microservices will communicate with the messaging platform over TLS, and the communication will be signed and encrypted in motion.

Transport layer security with authentication

It possible to implement authentication for communication between the microservices and the messaging platform. This will make sure only the microservices with valid credentials can communicate with the messaging platform and eventually with the other microservices.

According to the messaging platform you choose, you can implement authentication using a mechanism such as OAuth 2.0 or other mechanisms such as basic authentication or token-based authentication.

Transport layer security with authentication and authorization

The most secure approach to implement security for inter-service communication is to control the access using an authorization scheme that defines what microservices can access to what other microservices and channels.

With this approach, microservices are equipped with the credentials that have both the identity of the service and the entitlements to access data from other services.