How Alibaba Cloud Service Mesh ASM Enables Zero‑Trust Security for Kubernetes

Background and Motivation

The Log4j remote code execution vulnerability (CVE‑2021‑44228) demonstrated that unauthenticated users can inject malicious data into logs, leading to arbitrary code execution. Because Log4j is widely used in microservice frameworks, each microservice becomes a potential attack surface. Kubernetes orchestrates microservices but, by default, inter‑service traffic uses plain‑text HTTP, which does not satisfy modern security requirements. A zero‑trust approach is needed to require explicit authentication and least‑privilege authorization for every request, both inside and outside the network perimeter.

Zero‑Trust and Service Mesh

Zero‑trust, coined by Forrester analyst John Kindervag, means no implicit trust anywhere—every request must be authenticated and authorized based on context. Service mesh technology provides a practical way to enforce zero‑trust in a microservice architecture without sacrificing developer productivity. It adds strong identity verification, context‑aware authorization, encryption, and audit logging.

Alibaba Cloud Service Mesh (ASM) Overview

ASM is a cloud‑native, zero‑trust solution that offloads identity and authorization from application code to the mesh layer. Built on top of Kubernetes Network Policy, ASM adds:

Workload identity compatible with the SPIFFE standard.

Certificate management (issuance, rotation, lifecycle) using X.509 TLS.

Policy enforcement via Istio RBAC and fine‑grained Open Policy Agent (OPA) policies.

Observability of policy execution through logs and metrics.

Zero‑Trust Capability Building Blocks

Workload Identity : Defines a unique SPIFFE identity for each workload.

Security Certificates : ASM issues X.509 certificates for sidecar proxies and handles automatic rotation.

Policy Execution Engine : Supports Istio RBAC and OPA for granular authorization.

Visibility & Analytics : Provides dashboards and logs to monitor policy decisions.

Workload Identity in ASM

When a workload runs inside the mesh, ASM assigns a SPIFFE identity of the form

spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

. This identity is used for mutual TLS verification and as a selector in authorization policies.

Peer Authentication (Mutual TLS)

ASM supports two modes of peer authentication:

Strict mTLS : All traffic must present valid certificates; non‑TLS connections are rejected.

Permissive mTLS : TLS is preferred but non‑TLS traffic is still allowed.

Example to enforce strict mTLS for the details service:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: details-strict
  namespace: default
spec:
  mtls:
    mode: STRICT
  selector:
    matchLabels:
      app: details

After applying the policy, a plain‑HTTP request from the productpage pod fails with error code 56, indicating TLS is required. Switching the mode to PERMISSIVE restores HTTP access.

Request Authentication (JWT)

ASM can enforce JWT validation on inbound requests. Define a RequestAuthentication resource with the issuer and JWKS URL, then apply it to the target workload. Valid JWTs receive a 200 response, invalid tokens return 401, and requests without a token are allowed unless an additional AuthorizationPolicy restricts them.

export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ... (truncated)

Using the token in a curl request from the productpage pod:

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null \
  --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}
'

Returns 200. An invalid token returns 401, and a request without a token also returns 200 unless an AuthorizationPolicy is added.

Authorization Policy

To require a JWT for all requests, create an AuthorizationPolicy that allows only principals matching the issuer:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals:
        - [email protected]/[email protected]
  selector:
    matchLabels:
      app: details

Without a valid JWT, the request now receives 403 Forbidden.

OPA Integration

ASM integrates the Open Policy Agent (OPA) as a plug‑in, enabling fine‑grained, dynamically updatable access control policies. OPA policies are deployed as sidecar services and consulted by the mesh for each request.

Performance Optimizations

Intel Ice Lake processors introduce Crypto Acceleration and Multi‑Buffer technologies that accelerate TLS handshakes. ASM leverages these via Intel IPP, intel‑ipsec‑mb, and QuickAssist (QAT), enabling parallel processing of multiple private‑key operations and significantly improving encrypted communication throughput.

Summary of ASM Zero‑Trust Features

Managed certificate authority with automated rotation.

Control‑plane API for distributing authentication and authorization policies.

Sidecar‑based policy enforcement point (PEP).

Envoy extensions for telemetry and audit.

Workload‑level X.509 identity and automatic key rotation.