Pros and cons of monolithic vs. microservices architecture Build and deploy a microservice with Kubernetes
Tip

8 fundamental microservices security best practices

Despite the benefits, microservices will introduce profound security issues. We review the biggest microservices security challenges and eight strategies used to combat them.

Microservices architecture promises faster time to market, better scalability and loosely coupled components compared to monolithic builds. However, a conglomeration of several small autonomous services comes at a security cost: It complicates service-to-service communication, fragments data consistency and increases attack surfaces.

When you are working in a microservices-based application, a simple firewall will not suffice. The microservices design needs a much more layered defense to combat threats. The application's security must be a fundamental part of its architecture; microservices developers should build the application's security framework right from the beginning.

These eight microservices security best practices will help you to avoid these pitfalls. Adopt all of them when building applications.

1. Build security into the design

Microservices security best practices aren't just about deploying the right technology. For a successful microservices adoption, the development and operations teams should converge in line with the concept of DevOps, but they should also have a close relationship with security groups to understand security processes and how to mitigate security risks.

This approach, known as DevSecOps, dictates that developers and operations staff should make security teams part of the initial application design process -- rather than only consulted after things go into production.

DevSecOps tasks
What developers need to do in DevSecOps.

2. Protect your data

Always take appropriate measures to keep your data safe. Enforce HTTPS to secure data in transit and encryption to secure the data while it is at rest. HTTPS protects the privacy and integrity of data sent over the internet by encrypting the connection.

In addition, you can utilize the HTTP Strict Transport Security response header to tell browsers to only access your endpoints via HTTPS communication. It is also advisable to encrypt data early and decrypt it late -- in other words, decrypt only when needed -- to reduce the chances of exposure.

3. Use the API gateway

In a typical microservices-based application, ideally service consumers do not communicate with microservices directly. Rather, an API gateway provides a single point of entry for traffic and directs it to various microservices. The API gateway often uses token-based authentication to manage services' data privileges and dictate how they can interact with that data.

Since the clients don't directly access the services, they cannot exploit the services on their own. Place the API gateway behind a firewall to add a layer of protection, and ensure all the microservices used in a particular application are secure.

A basic architecture with microservices and an API gateway.
A basic model of how services and an API gateway interact. The API gateway manages requests for and delivery of services and microservices. This includes translations, availability, security and monitoring.

4. Implement rate limiting

Rate limiting is a concept that ensures an application accepts and processes a maximum of n requests within a specified duration of time, where n is a positive integer. This helps ward off an attacker that tries to break into an application with many different combinations of credentials.

Rate limiting is an excellent way to prevent denial-of-service attacks and your credentials from being compromised. Typically, you should implement rate limiting in the API gateway.

5. Practice defense in depth

Defense in depth is a strategy in which an application incorporates several layers of security control. Sensitive services get layers of security cover, so a potential attacker who has exploited one of the application's microservices can't invade another microservice or other layers of the application.

Don't depend on a single, seemingly robust security measure -- use all the security measures at your disposal to create layers of security between your microservices and potential attackers. For instance, even if you already have a strong network perimeter firewall in place, you should still practice strong token-based identification, keep addresses of sensitive microservices private and maintain a strong monitoring layer that diligently identifies unusual behavior.

Common security challenges in microservices

The distributed nature of microservices creates inherent complexities and security issues that development teams have no choice but to address. Here are the most notable microservices security challenges:

A large attack surface. The proliferation of communications interfaces in a microservices-based application increases the overall attack surface. Each exposed API and communication channel creates a potential attack vector that developers must address.

Insufficient log analysis. A microservices-based application typically has distributed stateless services that are developed through heterogeneous technologies. Logs are not all in the same format or generated in the same way. It's also possible that these services interact across large geographical distances. Create a system to aggregate logs so security analysts can correlate events that occur across diverse and disparate platforms.

Poor testing. Microservices developers can create, deploy and manage services independent of each other, which means they can quickly release services without thorough testing -- but testing catches security vulnerabilities. Although one of the greatest benefits of microservices-based applications is the freedom to release frequently, this improved agility must be tethered to proper testing.

Low fault tolerance. Fault tolerance in a microservices-based application is much more complex compared to that in a monolithic application. When the number of services communicating over the network increases, complexity increases, making faults more likely. If any microservice cannot properly cope with failures, it can destabilize the entire application and any other applications it works with.

6. Isolation

Isolation is one of the core principles of microservices architecture. Each service should be developed, tested, deployed, scaled and maintained independent of all other services. This isolation extends to the database as well. Typically, each microservice has its own copy of the data.

This isolation ensures that if one microservice is compromised, it can't access the data of another microservice. Another benefit is that in the event of a failure, the failed microservice will not bring down the other microservices in the application.

7. Secure at the container level

Microservices applications often use containers for deployment. Containers are based on images, which can introduce security vulnerabilities. Perform scanning at regular intervals to ensure that you use safe images and don't carry over any security problems.

Additionally, adhere to the principle of least privilege to secure your containers. To do this, you need to restrict access to resources and manage the usage of those resources. Provide access to a resource only on an as-needed basis. Additionally, you should not store any secrets in the container.

8. Monitor everything

Developers and security staff should work together to determine how to constantly and automatically monitor microservices-based applications for potential threats. Monitoring tools, such as Prometheus and InfluxDB, can bolster centralized monitoring capabilities.

Automated code scanning and continuous code updates are also essential. DevOps and security teams should work closely together to monitor code and prevent any unauthorized access to a resource in the application.

Dig Deeper on Application development and design

Software Quality
Cloud Computing
TheServerSide.com
Close