Zero Trust Network for Microservices With Istio

Security was mostly perimeter-based while building monolithic applications. It 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 Istio, with ZTN philosophy, 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 (server) receives a request from another service (client), 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).

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 that point to why a ZTN environment is necessary for microservices:

1. 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.

2. Increased network and security breaches: Data and security breaches among cloud providers are increasingly common since applications moved to public clouds. In 2022, nearly half of all data breaches occurred in the cloud.

3. 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 need a lot of customization and development to define and implement security and routing policies in the multicluster and multicloud traffic. Thus, configuring and managing consistent network policies and firewall rules for each service becomes an everlasting and frustrating process.

4. 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.

5. 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. In practice, Istio service mesh can help Ops and SREs to implement ZTN and secure microservices across the cloud.

How Istio Service Mesh Enables ZTN for Microservices

Istio is a popular open-source service mesh implementation software that provides a way to manage and secure communication between microservices. Istio abstracts the network into a dedicated layer of infrastructure and provides visibility and control over all communication between microservices.

Istio works by injecting an Envoy proxy (a small sidecar daemon) alongside each service in the mesh (refer to fig. B). Envoy is an L4 and L7 proxy that helps in ensuring security connections and network connectivity among the microservices, respectively. The Istio control plane allows users to manage all these Envoy proxies, such as directly defining and cascading security and network policies.

Istio simplifies enforcing a ZTN environment for microservices across the cloud. Inspired by Gartner Zero Trust Network Access, I have outlined four pillars of zero trust network that can be implemented using Istio.

1. Enforcing Authentication With Istio

Security teams would be required to create authentication logic for each service to verify the identity of users (humans or machines) that sent requests. The process is necessary to ensure the trustworthiness of the user.

In Istio, it can be done by configuring peer-to-peer and request authentication policies using PeerAuthentication and RequestAuthentication custom resources (CRDs):

1. Peer authentication policies involve authenticating service-to-service communication using mTLS. That is, certificates are issued for both the client and server to verify the identity of each other.
   
   Below is a sample PeerAuthentication resource that enforces strict mTLS authentication for all workloads in the foo namespace:

   YAML

    

   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
   metadata:
     name: default
     namespace: foo
   spec:
     mtls:
       mode: STRICT

   
   

2. Request authentication policies involve the server ensuring whether the client is even allowed to make the request. Here, the client will attach JWT (JSON Web Token) to the request for server-side authentication.
   
   Below is a sample RequestAuthentication policy created in the foo namespace. It specifies that incoming requests to the my-app service must contain JWT that is issued, and verified using public keys by entities mentioned under jwtRules.

   YAML

    

   apiVersion: security.istio.io/v1beta1
   kind: RequestAuthentication
   metadata:
     name: jwt-example
     namespace: foo
   spec:
     selector:
   	matchLabels:
     	app: my-app
     jwtRules:
     - issuer: "https://issuer.example.com"
   	  jwksUri: "https://issuer.example.com/keys"

   Both authentication policies are stored in Istio configuration storage.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
    	namespaces: ["dev"]
    to:
    - operation:
    	methods: ["POST"]