1 of 57

Mazu

A Zero Trust Architecture for Service Mesh Control Planes

Aashutosh Poudel, Pankaj Niroula, Collin MacDonald, Lily Gloudemans, Stephen Herwig

1

Mazu is a Chinese sea goddess and the deity of seafarers.

2 of 57

Microservices

Caption

2

3 of 57

Microservices

  • Applications decomposed into small, loosely-coupled services

Caption

3

4 of 57

Microservices

  • Applications decomposed into small, loosely-coupled services
  • Benefits:
    • elasticity

Caption

4

5 of 57

Microservices

  • Applications decomposed into small, loosely-coupled services
  • Benefits:
    • elasticity
    • isolation

Caption

5

6 of 57

Microservices

  • Applications decomposed into small, loosely-coupled services
  • Benefits:
    • elasticity
    • isolation
  • Kubernetes automates autoscaling, orchestration, and recovery of microservices

Caption

6

7 of 57

Service Mesh

  • Application networking, security, and metrics collection
    • Retries, timeouts, and circuit breaks for service-to-service communication
    • Service discovery, load balancing, and health checking
    • Network telemetry — request latency, throughput, failures
    • Secure network communications with mutual authentication
    • …
  • Service mesh handles cross-cutting concerns at the infrastructure level

Caption

7

8 of 57

Service Mesh Architecture

Istio Service Mesh

  • Services are deployed on top of Kubernetes

Caption

8

9 of 57

Service Mesh Architecture

Istio Service Mesh

  • Services are deployed on top of Kubernetes
  • Application-aware proxies are deployed as sidecars alongside services

Caption

9

10 of 57

Service Mesh Architecture

Istio Service Mesh

  • Services are deployed on top of Kubernetes
  • Application-aware proxies are deployed as sidecars alongside services
  • Service proxies form the data plane handling all traffic

Caption

10

11 of 57

Service Mesh Architecture

Istio Service Mesh

  • Services are deployed on top of Kubernetes
  • Application-aware proxies are deployed as sidecars alongside services
  • Service proxies form the data plane handling all traffic
  • Control plane configures how the data plane secures and controls the traffic

Caption

11

12 of 57

Zero Trust Networking

  • Control plane acts as certificate authority (CA) issuing certificates to the services

Caption

12

13 of 57

Zero Trust Networking

  • Control plane acts as certificate authority (CA) issuing certificates to the services

Caption

13

14 of 57

Zero Trust Networking

  • Control plane acts as certificate authority (CA) issuing certificates to the services

Caption

14

15 of 57

Zero Trust Networking

  • Control plane acts as certificate authority (CA) issuing certificates to the services
  • Sidecars use issued certificates to establish mutual TLS connections

Caption

15

16 of 57

Zero Trust Networking

  • Control plane acts as certificate authority (CA) issuing certificates to the services
  • Sidecars use issued certificates to establish mutual TLS connections
  • Implicit trust in the cluster's CA, the most privileged component

Caption

16

17 of 57

Zero Trust Networking

  • Control plane acts as certificate authority (CA) issuing certificates to the services
  • Sidecars use issued certificates to establish mutual TLS connections
  • Implicit trust in the cluster's CA, the most privileged component
  • CA compromise allows attacker to impersonate application or issue rogue certificate

Caption

17

18 of 57

Zero Trust Networking

  • Sidecars tunnel communication between micro services using mutual TLS
  • Service mesh control plane acts as certificate authority (CA) issuing certificates to the sidecar proxies
  • Implicit trust in the CA within the cluster — most privileged component, once certificates are issued, sidecars use that to establish mutual TLS
  • Service mesh control plane compromise allows attacker to impersonate application, issue rogue certificate, and redirect traffic to malicious endpoints

Caption

18

Correlate numbers in here with text on the left

19 of 57

Research Question

Is it possible to deprivilege the service mesh’s local CA while maintaining microservice compatibility and performance?

Caption

19

20 of 57

Eliminate CA

Identity-based encryption (IBE)

Caption

20

21 of 57

Eliminate CA

Identity-based encryption (IBE)

Caption

21

22 of 57

Eliminate CA

Identity-based encryption (IBE)

Caption

22

23 of 57

Eliminate CA

Registration Based Encryption (RBE)

Caption

23

24 of 57

Eliminate CA

Registration Based Encryption (RBE)

Caption

24

25 of 57

Eliminate CA

Registration Based Encryption (RBE)

Caption

25

26 of 57

Eliminate CA

Registration Based Encryption (RBE)

Caption

26

27 of 57

Eliminate CA

Registration Based Encryption (RBE)

Caption

27

28 of 57

Registration Based Encryption

  • Replaces CA with a less powerful entity called the key curator (KC)
  • KC doesn’t store any secrets
  • KC manages the system’s public parameters, binding public keys to identities
  • Used as a cryptographically verifiable registry for service authentication
  • Users generate their public and private keys; register their identity and public keys with the key curator
  • KC gives the users non-secret supplementary information called user’s opening that the user users to decrypt cipher texts

28

29 of 57

Threat model

29

30 of 57

Threat model

30

31 of 57

Threat model

31

32 of 57

Threat model

32

33 of 57

Threat model

33

34 of 57

Threat model

34

35 of 57

Threat model

35

36 of 57

Threat model

36

37 of 57

Threat model

  • Attacker able to exploit service mesh control plane
    • Issue rouge certificates
    • Redirect traffic to malicious services
    • Impersonate legitimate applications
    • Spawn microservices

37

38 of 57

Design

Service bootstrap by Kubernetes

38

39 of 57

Design

RBE Identity for Services

39

40 of 57

Design

KC Setup and Service Registration

40

41 of 57

Design

KC Setup and Service Registration

41

42 of 57

Design

ID Registration

  • Use hash of Kubernetes-signed admin token and IP as RBE ID
  • Node-agents generate self-signed TLS certificate for the co-resident service
  • Node-agents generate the RBE public, secret key pair and register the RBE ID as well as the public key with the Key Curator

42

43 of 57

Design

Certificate Validation

43

44 of 57

Design

Certificate Validation

44

45 of 57

Design

Certificate Validation

45

46 of 57

Design

Certificate Validation

46

47 of 57

Design

Certificate Validation

47

48 of 57

Design

TLS handshake

  • Client verifying server’s certificate
    • Verify server’s admin token is valid (via Kubernetes)
    • Derive server’s ID as a hash of server’s admin token and IP
    • Challenge server to decrypt a nonce encrypted with server’s ID (ClientHello)
    • Verification succeeds if server returns the decrypted nonce (ServerHello)
  • Server’s validation works in an analogous fashion

48

49 of 57

Implementation

49

Registration Based Encryption

Port of EfficientRBE [1] in Go

Sidecar

Envoy Proxy

Certificate Validation

Node Agent

Certificate Generation�&�RBE Identity Creation

Service �Mesh

Istio

Replace local CA by �Key Curator (KC) server

Platform

Minikube�(Kubernetes cluster)

[1] Noemi Glaeser, Dimitris Kolonelos, Giulio Malavolta, and Ahmadreza Rahimi. 2023. Efficient Registration-Based Encryption. In ACM Conference on Computer and Communications Security (CCS)

50 of 57

Implementation

  • Istio service mesh
    • Replace the CA functionality of the service mesh with Key Curator
  • Envoy sidecar proxy
    • Modify the certificate validation between sidecars
  • Port of RBE implementation from Glaeser et al.

50

51 of 57

Evaluation

Data plane performance

  • Two pods benchmark test
    • Data path performance between two proxies
  • Measures the request latency across four proxy configurations
    • baseline (using mTLS and no Istio)
    • Istio with sidecars using mTLS
    • Istio with sidecars using plaintext (no mTLS)
    • Mazu

51

52 of 57

Evaluation

Data plane performance

  • 1 KB payloads
  • 1000 requests per second
  • Concurrent client connections
    • Ranging from 2 to 256

52

53 of 57

Evaluation

Data plane performance

  • 1 KB payloads
  • 1000 requests per second
  • Concurrent client connections
    • Ranging from 2 to 256
  • Average latency of 1.27x (+0.17ms) compared to Istio with mTLS

53

54 of 57

Limitations and Future Work

  • Byzantine Key Curator
    • Inconsistent registration views
    • Allows an attacker to use a token from one registration set into another
  • Future Work
    • Detect equivocation and network partitioning attacks

54

55 of 57

Limitations and Future Work

  • Trust in Kubernetes
    • Service bootstrap
    • Verify tokens during handshake
    • Revoke tokens on service termination
  • Future Work
    • Separate RBE ID-space for revocation

55

56 of 57

Summary

  • De-privilege service mesh control plane
  • Replace the CA with an unprivileged public key registry based on Registration Based Encryption
  • Reduce service mesh’s attack surface in the event of a compromise

56

57 of 57

Thank you

57

Mazu: A Zero Trust Architecture for Service Mesh Control Planes

Aashutosh Poudel, Pankaj Niroula, Collin MacDonald, Lily Gloudemans, Stephen Herwig

{apoudel01, pniroula, cmacdonald01, algloudemans, smherwig}@wm.edu

Mazu is a Chinese sea goddess and the deity of seafarers.