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. 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 to guide your monolith-to-microservices migration.
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.
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.
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.
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.
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.
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.
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.
Authentication 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 are all able to implement token-based authentication and authorization in your microservices architecture.
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.
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 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, Role-Based Access Control (RBAC), and Attribute-Based Access Control (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.
When Netflix decomposed their monolith in favour of a microservices architecture (which we covered in chapter 1), 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.
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.
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.
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.
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.
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.
Ready for the next in the series? Continue to “How to build scalable and performant microservices”.
Or, you can download the complete 10-part series in one e-book now: "Monolith to microservices migration: 10 critical challenges to consider"
Along with our e-book, consider a hands-on session. Book a free workshop with a Cerbos engineer to focus specifically on microservice access control for your stack.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。