Security Challenges in Microservices

Before the rise of cloud computing and small autonomous services built with containers, a typical application would consist of a monolith of code with a frontend, a backend and a database. Developers would take extra caution when updating their code because any change or bug could affect the entire application. 

As an alternative, microservices broke down applications into small interconnected services — each responsible for their discrete function, collaborating using APIs. Developers could now change or update a service without fear of disrupting other application functions. 

Many leading companies in the tech world have shifted their applications to microservices architectures — and for good reason. Microservices are easier to scale and take less time to develop than monolithic applications. Verified Market Research predicts that the microservice market will reach a value of $6.62 billion by 2030. However, this approach comes at the cost of increased complexity, especially regarding application security. 

This article covers some of the microservices challenges developers face when designing application security and how to overcome them. 

Let’s look at 6 key challenges in building secure microservices and a few best practices. 

A microservices architecture’s sheer number of components leads to a greater attack surface than in monolithic applications. Each microservice comes with additional entry points and handles access requests independently. Authentication must be dealt with at several points and the perimeters are less defined. Each microservice communicates using APIs that attackers can expose, leading to a significant increase in attack surface.   

It is imperative, therefore, to secure all infrastructure layers of a microservice application. To reduce the total attack surface, you should secure not only the ingress and egress points of the application but also all APIs and microservice entry points. Using automated end-to-end scanning can help teams monitor threats across all services. 

Microservices require greater collaboration between application development and IT operations (DevOps) teams throughout the application lifecycle. Both teams need to have a good understanding of all the processes involved so they can minimize security risks. Unfortunately, nearly 85% of all organizations reported facing problems with implementing DevOps, according to a 2020 survey by Atlassian. 

Because the services are built separately by different teams independent of each other, they lead to faster deployment. However, this separation and speed often results in a lack of security testing. Overlooking security to reach a quicker time-to-market can lead to vulnerabilities in the application, which are often discovered when it’s too late.

To ensure application security, DevOps teams should constantly test the written code and the continuous integration and delivery/deployment (CI/CD) pipelines at all stages of development. Any open-source DevOps tools used should also be evaluated from a security perspective. 

Implementing authorization in an application with hundreds or even thousands of services is a complex task. Not only do you need to enforce access control at the API gateway level for external requests, but also secure communication between microservices and follow the zero-trust security principle for all internal requests. Making any central policy changes would require developers to update each microservice individually.

To solve authorization issues in cloud-native microservices, consider deploying the Open Policy Agent (OPA). This unified policy engine allows developers to decouple policy code from the underlying application code. This decoupling means that policy can be updated or changed without disrupting service functions using a unified policy language. 

With OPA, you can enforce either role-based or fine-grained attribute-based access control (ABAC), according to what’s suitable for your application. You can use Styra Declarative Authorization Service (DAS) — a central control plane designed by the creators of OPA — to manage all OPA deployments across a microservice application. Styra DAS comes with pre-built policies that meet compliance and security standards. It lets you monitor access control in real time and enables dev teams to see the impact of policies and catch violations before deployment. 

Microservices with a large number of small services usually have several different teams working on them. These teams have the freedom to choose the most optimal programming language and technology stack when planning design and implementation, resulting in a polyglot architecture. 

Instead of being able to use a centralized security team, this architecture creates a need for security experts who specialize in a particular technology stack. The best approach is to supplement a centralized team with specialized cybersecurity engineers in each microservice team. 

Traditional logging methods are insufficient for applications consisting of multiple distributed, stateless independent components. Services created using different technologies are often multi-cloud and result in various log structures. Each service maintains its own data set, and managing event logging mechanisms can become complex as the number of services increases. Teams can have difficulty figuring out the issue and the request flow if a service fails. 

Microservices logging should be centralized and standardized across all services to avoid these problems. The application should also be able to aggregate logs from all services and present all relevant information in a visual format so teams can quickly understand what went wrong. A unique correlation ID assigned to each service can also help developers determine where the fault occurred, as long as it is included in the logging data. 

Deploying microservices implemented as containers is the easiest way to create isolation and enforce custom security measures. These containers are based on images, which may contain vulnerabilities and can be compromised. One compromised container can affect all other containers running on the same host operating system. 

Adopting the security principle of least privilege, along with throttling and monitoring access to available resources, can help ensure container security. Using a container orchestration tool such as Kubernetes can significantly speed up the deployment while automating security processes. And for a declarative model that shifts security left and lets you put guardrails around Kubernetes, you can deploy Styra DAS. 

Styra Academy has a free course on microservices authorization, teaching you how to design and implement security and policy as code across your cloud-native architecture.

Enroll for free and start learning today.