Read Time:5 Minute, 37 Second
This blog was written by an independent guest blogger.
Microservices architecture is a convenient way to silo different software services compared to traditional software architecture and design. However, with multiple microservices communicating amongst each other – the attack surface of the network is greatly increased.
The security of such a system depends on the security of all the services. Any deviation in the system’s security ultimately undermines the integrity of the entire network. The number of vulnerabilities in a network based on microservices architecture can quickly grow from several to thousands of individual links depending on the number of services and how they communicate together.
This article will examine edge security in the context of microservices deployments and how APIs and API gateways set up at the edge can be used to secure service-to-service communications in a zero-trust environment.
A quick rundown on microservices
There is no single definition for what qualifies as a microservice. However, over time developers and industry standards have accepted a few key ideas. Microservices function similarly to how WordPress plugins provide a variety of siloed services on a website.
First, services in a microservice architecture typically communicate amongst one another on a network using protocols like HTTP. One advantage to utilizing a microservices architecture is that it greatly enhances the speed of your entire network. These services are then organized based on their function and developed independently of one another (and are also independently deployable).
Why microservices security is vital
Ensuring that your microservices architecture is secure is essential. Hackers can use phishing scams to steal credentials and break into your network. So, if you build a network that has only a single point of security, you may find that a single breach can give hackers access to any number of services within your entire network.
Outdated software can easily lead to network vulnerabilities. By establishing a system to secure each microservice you can prevent hackers from spreading their reach if they manage to crack into a single service.
Defining a Zero-Trust environment
A zero-trust environment in a cybersecurity context means the elimination of trust between individual parts of a digital system, which would otherwise expose those parts to security vulnerabilities. Although some connections are obvious, cybersecurity consultation can help you assess how vulnerable your network is.
Essentially, by siloing a network’s set of services and then eliminating their ability to trust one another we can increase security. If you find that you are unable to remove trust in your microservices architecture, the least you can do is minimize trust between services. Often businesses that have had their internal security breached, have had to seek reputation management services to protect their brand.
Another way to think of it is like this: your network represents a house that is full of rooms and each room is a service. Eliminating trust means locking all the doors to each room and then requiring a key every time a user wants to open that door.
Establishing security in service-to-service communications
How do we go about creating this security? Typically, when a microservices architecture is used, HTTP or gRPC are used to communicate in real-time. Apache Kafka and RabbitMQ are also examples of other communication protocols for applications. In order to secure these messages, we need to make sure that requests from a client application not only pass through security at the edge, but also internally.
How to build reliable authentication and authorization using mTLS
One way to make sure that access between services is secure is to implement authentication between services using Mutual Transport Layer Security (mTLS). However, in order to increase security, requests must be validated at the edge of the microservice and not just the edge of the network.
Each microservice then validates the certificate of the calling microservice and determines whether the certificate itself and the certificate’s issuer are trusted. Once the microservice has identified the caller, the microservice performs an authorization based only on the authentication credentials provided. This will check whether the caller is even able to do what it is requesting.
One way to enhance open source security and increase authentication and authorization speed is to utilize a proxy component that is deployed alongside the microservices. The proxy then intercepts all the calls that are placed to and from the microservice and prevents them from accessing the microservice directly.
Cryptographically safe methods for passing user context among microservices
The next step is to ensure that user context is passed securely between microservices. It’s important to ensure your network is secure, but also to ensure that communications intra-network are also secure.
The most common way this system works is by placing an API gateway at the edge of the microservices architecture deployment. The API gateway checks and validates user context corresponding to the application that made the call. Typically, the calling application can run the API just by itself, or for another user.
In either case, the API gateway acts like a sluice to regulate the flow of user context calls. When carrying these calls, the best way to cryptographically carry them is by using a JSON Web Token (JWT).
At the edge of the microservice, the JWT will be validated to make sure that it comes from a trusted issuer. Then, when one microservice communicates to another, the calling microservice can either feed the validated JWT to the new service or exchange it for a new JWT by communicating with another security token service that the recipient microservice trusts.
This way, one microservice could have an independent security token service separate from another verification service. This double-redundancy further strengthens the security of your services.
Once the end-microservice has verified the JWT, it can authorize the calling user based on the credentials that the JWT carries. Like with authentication and authorization, a proxy component intercepts these requests that come in and out of the microservice.
A functioning microservices security framework
Your entire network is only as secure as its weakest link. Every day businesses leave their data unprotected and vulnerable to hackers. Securing your microservices through multiple layers of security is one way to minimize these attack vectors. However, even if you take all of these steps it’s still important to consider threat detection and monitoring services.
Upgrade the security of your microservices architecture and consider where your vulnerabilities are in order to prevent unauthorized access to one microservice bleeding through to your other services. When you develop microservices as silos remember to utilize proxies and silo the security of the services by using JWT and mTLS. Your end goal should be to minimize trust, or if possible, establish a zero-trust environment.
