Home/Learn/Microservices/Zero-Trust Networking

Zero-Trust Networking

Advanced

Security

No implicit trust is granted based on network location; every request is authenticated and authorised, enforced by a service mesh (Istio/Linkerd) or explicit token validation.

Overview

Zero-Trust rejects the traditional "castle-and-moat" model where anything inside the network perimeter is trusted. Instead, every service-to-service call must present verifiable identity (mutual TLS / JWT), and access decisions are made per-request based on identity, device posture, and context. In Kubernetes microservices, a service mesh like Istio implements mTLS automatically between sidecar proxies without application-level changes. Outside a mesh, services validate Bearer tokens (JWTs) issued by a central identity provider (e.g. Keycloak, Auth0). The principle of least privilege is enforced via fine-grained RBAC/ABAC policies at the mesh or application level.

mTLS with Istio

Istio's PeerAuthentication policy enables mutual TLS cluster-wide or per namespace. The Envoy sidecar handles certificate rotation via SPIFFE/SPIRE, so services never manage certs directly. AuthorizationPolicy restricts which service identities may call which paths.

YAML — Istio PeerAuthentication + AuthorizationPolicy

# Enable STRICT mTLS for the entire namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: orders
spec:
  mtls:
    mode: STRICT

---
# Only allow order-service to call payment-service POST /payments
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-authz
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/orders/sa/order-service"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/payments"]

JWT Validation in Spring Security

Without a service mesh, services validate JWTs issued by an OAuth2 / OIDC provider. Spring Security's resource server support verifies the signature, expiry, and audience claims automatically.

Java — Spring Security OAuth2 resource server JWT validation

# application.yml
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://auth.example.com/realms/myrealm

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/actuator/health").permitAll()
                .anyRequest().authenticated())
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(jwt -> jwt.jwtAuthenticationConverter(jwtConverter())))
            .build();
    }
}

Service Identity with SPIFFE

SPIFFE (Secure Production Identity Framework For Everyone) provides standardised workload identity via SVIDs (SPIFFE Verifiable Identity Documents). Each pod is assigned a SPIFFE ID like spiffe://cluster.local/ns/orders/sa/order-service, used as the principal in mTLS and authorisation policies.

Java / YAML — SPIFFE workload identity enforcement

# Service Account binding (Kubernetes) — SPIFFE ID derived from this
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: orders

# Verify identity in Spring via a custom JwtAuthenticationConverter
// Extract service principal from "sub" claim or x509 SAN URI
Jwt jwt = ...;
String spiffeId = jwt.getClaimAsString("sub"); // spiffe://cluster.local/ns/orders/sa/order-service
if (!allowedPrincipals.contains(spiffeId)) throw new AccessDeniedException("untrusted caller");

Key Points to Remember

1Never trust the network perimeter — every request must carry verifiable identity
2mTLS authenticates both caller and callee; Istio automates cert rotation via SPIFFE/SPIRE
3AuthorizationPolicy (Istio) or Spring Security restrict access to specific service identities
4JWTs carry claims (sub, roles, aud) that are validated cryptographically — no session state needed
5Least privilege: grant only the minimum permissions each service needs to function
6Audit logs at the mesh layer capture every service-to-service call for compliance and forensics

Interview Questions

What is the difference between authentication and authorisation in a zero-trust model?

EasyGoogle

How does mutual TLS differ from one-way TLS?

MediumNetflix

What is SPIFFE and how does it provide service identity in Kubernetes?

HardCloudflare

How would you implement zero-trust without a service mesh?

HardAmazon

What does the "never trust, always verify" principle mean in practice?

MediumMicrosoft

Ask Aria about Zero-Trust Networking

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Discussion

Loading discussion…

Secrets Management

Containerisation with Docker