Introduction

The advent of cloud and container technologies have brought considerable change in how companies design their applications. Traditionally, applications were designed using a monolithic approach. These applications shared a single codebase containing all business logic for the various capabilities of the application [1]. This approach results in various parts of the application being tightly coupled making scaling individual parts difficult. As an alternative to monolithic architectures, we can use microservices. A microservice architecture “relies on small, loosely coupled services that communicate through well-defined APIs” [2]. A microservices approach breaks down the challenge of building an application into manageable chunks that run independent of each other and communicate over a shared network.

While microservices can greatly increase the pace of development for an application, they introduce a number of new challenges, especially in regards to networking. This includes support for things such as asynchronous interactions, service discovery, and load balancing. APIs must be clearly defined for each microservice and an orchestrator is often necessary to manage all the various services. These concerns plus the standard network security concerns present in all applications regardless of infrastructure paradigm, warrant a deeper look.

In this paper, we consider network security in the context of cloud microservice applications through the lens of confidentiality, integrity, and availability. A focus will be given on identity and access control as well as common vulnerabilities and attacks that can occur as a result of using microservices. Techniques to mitigate these attacks will also be discussed.

Confidentiality

At the core of information security is confidentiality, integrity, and availability, or the CIA triad. Confidentiality is the idea of preserving authorized restrictions on information access and disclosure. This includes both protecting personal privacy and proprietary information [3]. Microservices deployed as part of the same application will often have different access and deployment patterns. Because of these varying patterns, as well as the necessity to communicate between services, confidentiality can be particularly tricky. With microservices, “traditional mechanisms of user authentication are not sufficient” [4]. In contrast to monolithic applications, where confidentiality could be ensured by performing authentication and authorization at the start, each individual service in a microservice architecture “often needs to verify that the request is authorized to perform a certain operation” [4].

To ensure confidentiality, then, authorization and authentication itself can be thought of as a microservice. In their paper “Trusted Microservices: A Security Framework for Users' Interaction with Microservices Applications”, Elkholy and Marzok propose a security service responsible for authentication of the user and authorizing actions across microservices. This service issues a ticket to the user which can then be routed along with the user’s request to various microservices [4]. The security microservice approach varies significantly from more traditional network designs for handling authentication and authorization. Traditional monolithic applications would often assume that communication between the various parts of the application should be trusted. Various network security controls at the edge, such as firewalls and demilitarized zones, ensure confidentiality while traffic within the perimeter is trusted. This is not the case for microservices. Rather “we should assume that the other services in the system may be compromised and hostile” [5]. In other words, adopt a zero trust network access model.

A number of different approaches have emerged to ensure confidentiality using zero trust. One common one is through mutual transport layer security or mTLS. With mTLS, a central certificate authority generates a root certificate and is responsible for validating and issuing certificates to new services. Microservices within an application can then communicate securely with one another using their TLS certificates to prove to the other that they are legitimate. This ensures the confidentiality of all service-to service communication without blindly trusting any one service, with the exception of the certificate authority [5]. Using mTLS also improves defense against person-in-the-middle attacks and spoofing attacks. By encrypting all communication and requiring both parties to present valid certificates, it becomes significantly harder for a malicious actor to impersonate a service or insert themselves into a communication.

Integrity

Integrity is the idea of guarding against improper information modification or destruction as well as ensuring information non-repudiation and authenticity [3]. Typical implementations of microservice architectures rely heavily on HTTP requests. As a result, the same vulnerabilities we see crop up in other applications using HTTP appear here. Since HTTP does not provide any validation that the original message has not been tampered with and is in plaintext, person-in-the-middle attacks are straightforward. To mitigate this we can turn to encryption using HTTPS or, better yet, mTLS as discussed above. Encrypting network traffic keeps communication between services private. Now, our person in the middle will only see encrypted traffic so cannot make any meaningful modifications. Even if they made random modifications to the encrypted message to try breaking things, this would result in the receiving service getting a nonsensical message. Any message that is formatted incorrectly should be assumed to be malicious so the receiving service will know to ignore it.

What makes integrity a unique challenge for microservice architecture is implementing non-repudiation. The added network complexity that is introduced as the number of microservices in an application increases “greatly increases the difficulty in monitoring the security of the entire application” [6]. It becomes necessary to not only see who initiated a network request but to also follow the trail as that request makes its way across multiple microservices.. “Any function completion may require the communication among multiple microservices” [6].

To resolve this, it is crucial that a robust, centralized logging solution is implemented and network traffic flow be simplified. One common solution for this is to use API gateways. API gateways serve as a central hub for communication both from outside and within a microservice application. By having a central hub for all requests, monitoring traffic becomes significantly easier since all traffic must pass through the gateway [7]. We can then implement a logging solution on top of the API gateway that captures all network traffic. This makes tracking a request that spans multiple microservices easier since each individual network call must pass through the gateway.

Availability

Last is availability, which focuses on “ensuring timely and reliable access to, and use of, information” [3]. As with the previous two sections, availability for microservice applications is unique because individual components make calls to one another in order for the whole application to function. Because of this distributed nature there are fewer single points of failure for microservice applications. Modern container orchestration applications such as Kubernetes and Amazon Elastic Container Service all provide the ability for multiple, redundant instances of services. If one instance were to fail, traffic can be dynamically routed to other healthy instances ensuring availability [8]. Failure is often detected using health checks. In a health check, a controller sends a message to a service instance asking for a response. If the response fails or is malformed then the controller can assume that the container instance is unhealthy and traffic should be routed elsewhere. Health checking in combination with a load balancer allows for a microservice application to achieve high availability [9].

While redundant instances, load balancing, and health checking can ensure that availability between services is reliable, microservices applications can still be vulnerable to denial of service (DoS) attacks from external actors. DoS attacks occur when the network is flooded with requests, resulting in more traffic than the application can handle [10]. Any traffic entering from outside the application’s network should be treated as a potential opportunity for a DoS attack. As mentioned earlier, API gateways are often used to take in new requests and route traffic to relevant services. While convenient, API gateways can be one of the few single points of failure for microservice applications. Should the API gateway go down, communications between services will not be routed effectively and new requests cannot be handled properly.

To mitigate this problem, API gateways can use rate throttling. Rate throttling consists of “slowing down the response time of microservice applications if a deviation of its expected behavior is detected” [11]. Essentially, if atypical network behavior is detected by a specific device then the API gateway can deprioritize, or even completely drop those requests. This proactive sorting of incoming requests ensures that available bandwidth is used effectively and legitimate requests are more likely to be processed. Rate throttling can also be applied to individual microservices within the application. If requests from a microservice are consistently failing or coming in at a faster than expected rate, throttling can be applied to that microservice to slow it down and ease stress on the entire network. In addition to rate throttling, standard DoS protection for any network apply to microservice application networks as well such as using firewall rules to block illegitimate traffic and using caches to speed up frequent requests.

Conclusion

In this paper, we examined network security in microservice application architectures within the context of confidentiality, integrity, and availability. While non-exhaustive, a great start for ensuring network security is to consider these three main components. Overall, microservice applications have similar network security concerns as any other networked application. Valid authentication mechanisms are critical for ensuring confidentiality. Encryption in transit can improve integrity, and appropriate firewall rules at the border of the network ensure availability by helping to prevent DoS attacks.

However, microservice application networks are unique compared to monolithic applications because of their distributed nature. Splitting an application up into small, isolated components that communicate via APIs by necessity introduces more network traffic. Services must not only communicate outward to the user but potentially across several other services in order to complete a request. Authentication is required not just for incoming requests but also for communication between microservices themselves in order to avoid potential person in the middle attacks. Centralized logging across a network of components becomes necessary to ensure non-repudiation, a key part of integrity. Redundant containers, health checking, and load balancing all ensure that availability of an application is maintained even if some microservices go down. By considering the CIA triad we can begin to discover the requirements necessary for implementing a secure network with microservice applications.

References

[1] Schabell, E. (2023, August 1). Monolith vs. Microservice architecture for software delivery. The New Stack. https://thenewstack.io/monolith-vs-microservice-architecture-for- software-delivery/

[2] Amazon Web Services (2023, July 21). Implementing Microservices on AWS. AWS. Retrieved from https://docs.aws.amazon.com/pdfs/whitepapers/latest/microservices- on-aws/microservices-on-aws.pdf

[3] Cawthra, J., Ekstrom, M., Lusty, L., Sexton, J., & Sweetnam, J. (2020, December) NIST Special Publication 1800-26 Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events. NIST. Retrieved from https://www.nccoe.nist.gov/ publication/1800-26/index.html

[4] Elkholy, M., & A. Marzok, M. (2022). Trusted Microservices: A Security Framework for Users’ Interaction with Microservices Applications. Journal of Information Security and Cybercrimes Research (Online), 5(2), 135–143. https://doi.org/10.26735/QOPM9166

[5] Yarygina, T., & Bagge, A. H. (2018). Overcoming Security Challenges in Microservice Architectures. 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE), 11–20. https://doi.org/10.1109/SOSE.2018.00011

[6] Yu, D., Jin, Y., Zhang, Y., & Zheng, X. (2019). A survey on security issues in services communication of Microservices‐enabled fog applications. Concurrency and Computation, 31(22). https://doi.org/10.1002/cpe.4436

[7] Gadge, S., & Kotwani, V. (2017). Microservice Architecture: API Gateway Considerations. GlobalLogic. Retrieved from https://mainlab.cs.ccu.edu.tw/presentation/pdf/(2017) Microservice-Architecture-API-Gateway-Considerations.pdf

[8] Richter, D., Konrad, M., Utecht, K., & Polze, A. (2017). Highly-Available Applications on Unreliable Infrastructure: Microservice Architectures in Practice. 2017 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), 130–137. https://doi.org/10.1109/QRS-C.2017.28

[9] Casalicchio, E. (2019). Container Orchestration: A Survey. In Systems Modeling (pp. 221–235). Springer International Publishing. https://doi.org/10.1007/978-3-319- 92378-9_14

[10] Cloudflare (n.d.) What is a denial-of-service (DoS) attack? Cloudflare. Retrieved from https://www.cloudflare.com/learning/ddos/glossary/denial-of-service/

[11] Billawa, P., Bambhore Tukaram, A., Díaz Ferreyra, N. E., Steghöfer, J.-P., Scandariato, R., & Simhandl, G. (2022). SoK: Security of Microservice Applications: A Practitioners’ Perspective on Challenges and Best Practices. 17th International Conference on Availability, Reliability and Security, ARES 2022, Vienna, Austria, 1–10. https://doi.org/10.1145/3538969.3538986