Zero Trust Network

networking distributedsystem/microservice kubernetes/networking

Zero Trust Security | What’s a Zero Trust Network?
Zero Trust Architecture on Kubernetes with Istio Service Mesh | by Luca Passaretta | Medium
The Fallacies of Distributed Computing > 4. Network Is Secure

Core Idea

Zero Trust means never trust, always verify: authenticate by identity instead of network location, enforce least privilege and mTLS between services, and keep verifying.

Why perimeter security fails in microservices, where threats exist inside and outside the network.

The seven pillars: identity-based auth, least privilege, mTLS, service mesh enforcement, micro-segmentation, short-lived credentials, continuous verification and observability.

Key technologies section maps the pillars to tools.

“Never trust, always verify” this is the core principle of Zero Trust. Unlike traditional perimeter-based security (where everything inside the network is trusted), Zero Trust assumes that threats exist both outside and inside the network.

The Problem with Traditional Security in Microservices

In a monolith, once a request clears the firewall, it moves freely inside. In microservices, you have dozens (or hundreds) of services talking to each other — if one is compromised, an attacker can move laterally across your entire system with no friction.

Core Pillars of Zero Trust in Microservices

1. Identity-Based Authentication (Not Network Location)

Every service must prove who it is on every request — not just “it’s inside our VPC, so it’s fine.”

Services get cryptographic identities (e.g., SPIFFE)
mTLS (mutual TLS) ensures both caller and callee authenticate each other
Short-lived certificates minimize breach windows

Mutual TLS (mTLS)

2. Least Privilege Authorization

Each service can only do exactly what it needs — nothing more.

Service A can call Service B’s /read endpoint but not /delete
Enforced via RBAC/ABAC policies (e.g., Open Policy Agent)
Authorization is re-evaluated on every request, not just at login

3. Mutual TLS (mTLS) for Service-to-Service Communication

All traffic between services is encrypted and authenticated — even on the internal network.

Service A ──[client cert]──► Service B
Service A ◄──[server cert]── Service B
         Both sides verified ✓

4. Service Mesh as the Enforcement Layer

A service mesh (Istio, Linkerd, Consul) handles Zero Trust at the infrastructure level so developers don’t have to bake it into every service.

Sidecars (Envoy proxies) intercept all traffic
Policy is applied consistently, transparently
Centralized observability (who talked to whom, when)

5. Micro-Segmentation

Instead of one big flat network, services are isolated into fine-grained segments with strict ingress/egress rules.

Even if Service A is compromised, it can’t reach the Payment Service
Enforced via Network Policies (Kubernetes) or firewall rules

6. Dynamic, Short-Lived Credentials

No long-lived API keys or passwords sitting in config files.

Secrets managed by Vault (HashiCorp) or AWS Secrets Manager
Tokens expire quickly and rotate automatically

7. Continuous Verification & Observability

Trust is never assumed — every request is logged and evaluated.

Distributed tracing (Jaeger, Zipkin)
Anomaly detection on traffic patterns
Audit logs for every service-to-service call

Key Technologies

Concern	Tools
Service Identity	SPIFFE, SPIRE
mTLS / Traffic Encryption	Istio, Linkerd, Consul
Policy Enforcement	OPA (Open Policy Agent)
Secrets Management	HashiCorp Vault, AWS Secrets Manager
Network Segmentation	Kubernetes Network Policies, Cilium
Observability	Jaeger, Grafana, Promethues

Zero Trust in Kubernetes

Kubernetes
Observability

Layer 1 — Edge: Identity & Authentication

Every request entering the cluster is challenged at the API Gateway (Kong, Nginx, or AWS ALB). This is where JWT/OAuth2 tokens are validated. No token, no entry.

SPIFFE/SPIRE issues cryptographic SVID (SPIFFE Verifiable Identity Document) certificates to every workload — these short-lived X.509 certs replace long-lived passwords and API keys entirely.

# PeerAuthentication — enforce mTLS cluster-wide
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # No plaintext allowed anywhere

Layer 2 — Service Mesh: mTLS Everywhere

Istio injects an Envoy sidecar into every pod. All service-to-service traffic is automatically encrypted and mutually authenticated — developers don’t write a single line of TLS code.

# AuthorizationPolicy — deny all, then allow only what's needed
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-allow
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payment-svc
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/payments/sa/order-sa"]  # Only order-svc can call
    to:
    - operation:
        methods: ["POST"]
        paths: ["/v1/charge"]  # Only this endpoint

Layer 3 — Workloads: ServiceAccounts & Least Privilege

Service Accounts
Each pod gets a dedicated ServiceAccount — never the default one. Tokens are projected with a short expiry and bound to the pod’s lifetime.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-sa
  namespace: payments
automountServiceAccountToken: false  # Explicit opt-in only

Layer 4 — Policy: RBAC + OPA + NetworkPolicy

API security and RBAC

Three enforcement mechanisms work together:

Kubernetes RBAC controls what a ServiceAccount can do with the K8s API (list pods, read secrets, etc.). OPA/Gatekeeper enforces admission-time rules (e.g. “no pod may run as root”). NetworkPolicy (via Cilium or Calico) provides L3/L4 micro-segmentation.

# NetworkPolicy — payment-svc only accepts traffic from order-svc
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-ingress
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payment-svc
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: order-svc
    ports:
    - port: 8080

Layer 5 — Secrets: Vault + cert-manager

Never store secrets in environment variables or ConfigMaps. Use Vault for dynamic secrets (database credentials that auto-rotate every 15 minutes) and cert-manager for automatic TLS certificate renewal.

# Vault Agent auto-injects secrets as files
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "payment-role"
  vault.hashicorp.com/agent-inject-secret-db: "database/creds/payment-db"

Implementation Checklist

Step	Tool	What it achieves
1	Istio `PeerAuthentication`	Enforce STRICT mTLS cluster-wide
2	SPIFFE/SPIRE	Cryptographic workload identity
3	Istio `AuthorizationPolicy`	Deny-all + explicit allow rules
4	Dedicated `ServiceAccounts`	Per-workload identity for RBAC
5	`NetworkPolicy` via Cilium	L3/L4 micro-segmentation
6	OPA/Gatekeeper	Admission control guardrails
7	HashiCorp Vault	Dynamic, short-lived secrets
8	cert-manager	Automatic TLS rotation
9	Jaeger + Prometheus	Full traffic observability

Transclude of kubernetes-networking--and--service-mesh-architecture-guide#istio-and-cilium

Nimendra's Notes 🪴

Explorer