Enabling Zero Trust Networking for Microservices with Istio Service Mesh

Translator | Li Rui

Review | Chonglou

51CTO Reader Growth Plan Community Recruitment, Consulting Assistant (WeChat ID: CTOjishuzhan)

When building monolithic applications, security was primarily perimeter-based. This meant using firewalls to protect network boundaries and access controls. With the advent of microservices architecture, static and network-based boundaries are no longer effective.

Today, applications are deployed and managed by container orchestration systems such as Kubernetes, which are distributed across cloud platforms. Zero Trust Networking (ZTN) is a different approach to protecting data across cloud-based networks. This article will explore how Istio can help protect microservices using the Zero Trust Networking (ZTN) philosophy.

1. What is Zero Trust Network (ZTN)?

Zero Trust Networking (ZTN) 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 first continuously authenticate and authorize the client, and then allow communication to proceed securely (see Figure A).

Figure A: A Zero Trust Network (ZTN) environment that enforces continuous authentication and authorization between microservices in multiple clouds

2. Why is a zero-trust network environment inevitable for microservices?

The importance of protecting the network and data in a distributed service network cannot be overstated. Here are some of the challenges that point out why microservices require a zero trust network (ZTN) environment:

(1) Lack of network ownership: Applications move from perimeter-based to multiple cloud platforms and data centers with microservices. As a result, the network also becomes decentralized, providing more attack surfaces for network intruders.

(2) Increased network and security breaches: Since applications have been migrated to the public cloud, data and security breaches among cloud computing providers have become increasingly common. In 2022, nearly half of data breaches will occur in the cloud.

(3) Managing multi-cluster network policies has become tedious: Enterprises deploy hundreds of services in multiple Kubernetes clusters and environments. Network policies are local to the cluster and are usually not applicable to multiple clusters. They require a lot of customization and development to define and implement security and routing policies in multi-cluster and multi-cloud traffic. As a result, configuring and managing consistent network policies and firewall rules for each service becomes a long-lasting and frustrating process.

(4) In Kubernetes, service-to-service connections are inherently insecure: By default, a service can communicate with another service within the cluster. Therefore, if a service pod is hacked, a network attacker can quickly and easily attack other services in the cluster (also known as a vector attack). Kubernetes does not provide out-of-the-box encryption or authentication for communications between pods or services. Although Kubernetes provides additional security features, such as enabling mTLS, this is a complex process that must be implemented manually for each service.

(5) Lack of visibility into network traffic: If there is a security breach, operations and SRE teams should be able to respond to the incident more quickly. Poor real-time visibility into network traffic across environments becomes a bottleneck for SRE teams to diagnose problems in a timely manner. This hinders their incident response capabilities, resulting in a high mean time to recovery (MTTR) and catastrophic security risks.

In theory, the Zero Trust Network (ZTN) concept solves all of the above challenges. In practice, Istio service mesh can help operations and SRE teams implement cross-cloud Zero Trust Network (ZTN) and secure microservices.

How does Istio Service Mesh enable Zero Trust Networking (ZTN) for microservices?

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

The way Istio works is by injecting an Envoy proxy (a small sidecar daemon) next to each service in the mesh (see Figure B). Envoy is an L4 and L7 proxy that helps ensure secure connections and network connectivity between microservices, respectively. The Istio control plane allows users to manage all of these Envoy proxies, such as directly defining and cascading security and network policies.

Figure B: Istio uses the Envoy proxy to ensure service connectivity between clusters and cloud platforms

Istio simplifies the process of implementing a zero-trust network (ZTN) environment for microservices across cloud platforms. Inspired by Gartner's Zero Trust Network Access, we outlined four pillars that can be used to implement a zero-trust network using Istio.

Istio service mesh realizes the four pillars of zero trust network

1. Enforce authentication using Istio

The security team needs to create authentication logic for each service to verify the identity of the user (human or machine) sending the request. This process is necessary to ensure the trustworthiness of the user.

In Istio, it can be achieved by configuring peer and request authentication policies using the Peer Authentication and Request Authentication custom resources (CRDs):

(1) The peer authentication strategy involves using mTLS to authenticate service-to-service communications. That is, certificates are issued to the client and server to verify each other's identity.

The following is an example PeerAuthentication resource that enforces strict mTLS authentication for all workloads in the foo namespace:

YAML

 1 apiVersion: security.istio.io/v1beta1 2 kind: PeerAuthentication 3 metadata: 4 name: default 5 namespace: foo 6 spec: 7 mtls: 8 mode: STRICT

(2) Request authentication policy involves the server ensuring whether the client is allowed to make the request. Here, the client will attach a JWT (JSON Web Token) to the server-side authentication request.

Below is an example of a RequestAuthentication policy created in the foo namespace. It specifies that incoming requests to the my-app service must contain a JWT that is issued and verified using a public key by the entity mentioned in jwtRules.

YAML

 1 apiVersion: security.istio.io/v1beta1 2 kind: RequestAuthentication 3 metadata: 4 name: jwt-example 5 namespace: foo 6 spec: 7 selector: 8 matchLabels: 9 app: my-app 10 jwtRules: 11- issuer: "https://issuer.example.com" 12 jwksUri: "https://issuer.example.com/keys"

Both authentication policies are stored in the Istio configuration store.

2. Implementing Authorization with Istio

Authorization verifies whether an authenticated user is allowed to access the server (access control) and perform specific operations. Continuous authorization prevents malicious users from accessing the business, thus ensuring its security and integrity.

Authorization Policy is another Istio CRD that provides access control for services deployed in the mesh. It helps in creating deny, allow policies, and perform custom actions on inbound requests. Istio allows setting multiple policies with different actions to achieve fine-grained access control to workloads.

The following Authorization Policy denies POST requests from workloads in the dev namespace to workloads in the foo namespace.

YAML

 1 apiVersion: security.istio.io/v1beta1 2 kind: AuthorizationPolicy 3 metadata: 4 name: httpbin 5 namespace: foo 6 spec: 7 action: DENY 8 rules: 9 - from: 10 - source: 11 namespaces: ["dev"] 12 to: 13 - operation: 14 methods: ["POST"]

3. Istio’s multi-cluster and multi-cloud visibility

Another important pillar of Zero Trust Network (ZTN) is network and service visibility. SRE teams and operations teams need to monitor traffic between microservices across cloud platforms and cluster boundaries in real time. A deep understanding of the network will help the SRE team quickly identify the root cause of anomalies, develop solutions, and restore applications.

Istio provides visibility into communication flows and application health by collecting the following telemetry data from the mesh in the data and control plane.

(1) Logs: Istio collects various logs, such as service logs, API logs, access logs, gateway logs, etc., which will help understand the behavior of the application. Logs also help to troubleshoot and diagnose network events faster.

(2) Metrics: They help understand the real-time performance of services to identify anomalies and fine-tune them at runtime. Istio provides many metrics in addition to the 4 golden metrics (error rate, traffic, latency, and saturation).

(3) Distributed tracing: It is the tracking and visualization of requests flowing through multiple services in the mesh. Distributed tracing helps understand the interactions between microservices and provides a holistic view of service-to-service communication in the mesh.

4. Use Istio for network auditing

Auditing is the analysis of logs of a process over a period of time with the goal of optimizing the overall process. Audit logs provide auditors with valuable insights into network activities, including details of each access, methods used, traffic patterns, etc. This information is very useful for understanding communication processes within and outside of data centers and public clouds.

Istio provides information about who accessed (or requested to access), when, and what resource was accessed, which is very important for auditors to investigate error conditions. Auditors need this information to recommend steps to improve the overall performance of the network and the security of cloud-native applications.

4. Deploy Istio for a better security posture

In a microservices architecture, the challenge of protecting the network and data becomes increasingly complex. Cyber ​​attackers are always able to discover and exploit vulnerabilities before anyone on the SRE team has time to notice them.

Implementing zero-trust networking will provide visibility and protection for Kubernetes clusters from internal or external threats. Istio service mesh can lead this effort from the front end by enabling zero-trust capabilities out of the box.

Original link: https://dzone.com/articles/zero-trust-network-for-microservices-with-istio-1