Zero Trust Architecture

Why Zero Trust¶

The traditional security model assumes the network perimeter separates trusted from untrusted. The 2025 reality:

• Cloud-native — Services run in Azure, AWS, on-premise. Where is the perimeter?
• Remote work — Employees work from anywhere. VPN is not enough.
• Supply chain — Third-party integrations, SaaS tools, external APIs. Who is “inside”?
• Lateral movement — An attacker compromises one endpoint and moves freely through the network.

Zero Trust says: no implicit trust. Every request is verified — regardless of where it comes from.

Implementation pillars¶

1. Identity & Authentication¶

Users: - SSO via identity provider (Azure AD, Okta, Auth0) - MFA mandatory for everyone — FIDO2/WebAuthn preferred (phishing-resistant) - Conditional access policies — context decides (device, location, risk score) - Passwordless wherever possible

Services (workload identity): - SPIFFE/SPIRE for workload identity — every service has a cryptographically verifiable identity - Service accounts with minimal permissions - Managed identities (Azure MI, AWS IAM roles) instead of long-lived credentials - Automatic certificate rotation, with no downtime

2. Mutual TLS (mTLS)¶

Service-to-service communication encrypted and mutually authenticated:

• Service mesh (Istio, Linkerd) — mTLS transparently for all services in the cluster
• Certificate management — Automatic rotation, short-lived certificates (24h)
• No plaintext — No unencrypted communication, even on the internal network
• Observability — You see who communicates with whom and how much data flows

3. Micro-segmentation¶

Network policies at the workload level:

• Kubernetes NetworkPolicy — Default deny, explicit allow rules
• Cilium — eBPF-based enforcement, L7 policy (HTTP method, path)
• Service mesh policies — AuthorizationPolicy in Istio (who may call whom)
• East-west firewall — Control of lateral traffic, not just north-south

Example: order-service may communicate with inventory-service and payment-service. No other service. An attacker who compromises notification-service cannot reach orders.

4. Least Privilege & JIT Access¶

RBAC granularity: - Roles defined per service, per environment (dev/staging/prod) - No wildcard permissions (*:*:*) - Regular access reviews — who has access to what and why

Just-in-Time (JIT) access: - An administrator does not need permanent prod access - Request access → approval → time-boxed permission (2–4h) → automatic revocation - Audit trail of every access - PAM (Privileged Access Management) for critical systems

5. Continuous Verification¶

Zero Trust does not end with authentication:

• Device posture — Is the device managed? Current OS? Endpoint protection running?
• Behavioral analytics — Anomalies in user behavior (unusual login time, location, access pattern)
• Session re-evaluation — Risk score is recalculated continuously, not just at login
• Adaptive policies — Elevated risk → step-up authentication required

Implementation roadmap¶

Phase 1: Visibility (Month 1–2)¶

• Inventory of all services, users, data flows
• Monitoring of east-west traffic — who communicates with whom
• Baseline for normal behavior
• Gap analysis against Zero Trust principles

Phase 2: Identity Foundation (Month 2–3)¶

• SSO + MFA for all users
• Workload identity (SPIFFE/SPIRE or managed identities)
• Service mesh deployment (mTLS in permissive mode — logs, does not block)

Phase 3: Enforcement (Month 3–5)¶

• mTLS strict mode — unencrypted communication blocked
• NetworkPolicy / AuthorizationPolicy enforcement
• JIT access for admin operations
• Least privilege audit and remediation

Phase 4: Continuous (Ongoing)¶

• Behavioral analytics and anomaly detection
• Quarterly access reviews
• Policy-as-code — GitOps for security policies
• Red team exercises focused on lateral movement

Technology¶

Istio, Linkerd, Cilium, SPIFFE/SPIRE, Azure AD / Entra ID, Okta, HashiCorp Vault, Kubernetes NetworkPolicy, Open Policy Agent (OPA), Falco, CrowdStrike, Microsoft Defender for Cloud.