Security was mostly perimeter-based while building monolithic applications. This means securing the network perimeter and access control using firewalls. With the advent of microservices architecture, static and network-based perimeters are no longer effective.
Nowadays, applications are deployed and managed by container orchestration systems like Kubernetes, which are spread across the cloud. Zero trust network (ZTN) is a different approach to secure data across cloud-based networks. In this article, we will explore how ZTN can help secure microservices.
What is Zero Trust Network (ZTN)?
Zero trust network is a security paradigm that does not grant implicit trust to users, devices, and services, and continuously verifies their identity and authorization to access resources.
In a microservices architecture, if a service (client) receives a request from another service (server), the server should not assume the trustworthiness of the client. The server should continuously authenticate and authorize a client first and then allow the communication to happen securely (refer to fig. A below).
Fig. A – A Zero Trust Network (ZTN) environment where continuous authentication and authorization are enforced between microservices across multicloud
Why is a zero trust network environment inevitable for microservices?
The importance of securing the network and data in a distributed network of services cannot be stressed enough. Below are a few challenges why a ZTN environment is necessary for microservices:
- Lack of ownership on the network: Applications moved from perimeter-based to multiple clouds and data centers with microservices. As a result, the network has also got distributed, giving more attack surface to intruders.
- Increased network and security breaches: Data and security breaches among cloud providers have become increasingly common since applications moved to public clouds. In 2022, nearly half of all data breaches occurred in the cloud.
- Managing multicluster network policies has become tedious: Organizations deploy hundreds of services across multiple Kubernetes clusters and environments. Network policies are local to clusters and do not usually work for multiple clusters. They require a lot of customization and development to define and implement security and routing policies in multicluster and multicloud traffic. Thus, configuring and managing consistent network policies and firewall rules for each service becomes an everlasting and frustrating process.
- Service-to-service connection is not inherently secure in K8s: By default, one service can talk to another service inside a cluster. So, if a service pod is hacked, an attacker can quickly hack other services in that cluster easily (also known as vector attack). Kubernetes does not provide out-of-the-box encryption or authentication for communication between pods or services. Although K8s offers additional security features like enabling mTLS, it is a complex process and has to be implemented manually for each service.
- Lack of visibility into the network traffic: If there is a security breach, the Ops and SRE team should be able to react to the incident faster. Poor real-time visibility into the network traffic across environments becomes a bottleneck for SREs to diagnose issues in time. This impedes their ability for incident response, which leads to high mean time for recovery (MTTR) and catastrophic security risks.
In theory, a zero trust network (ZTN) philosophy solves all the above challenges. Istio service mesh helps Ops and SREs to implement ZTN and secure microservices across the cloud.