Zero Trust Architecture

Chapter 32: Zero Trust Architecture

Learning Objectives

Understand Zero Trust principles and why perimeter security fails
Design a Zero Trust network architecture
Implement identity-based access controls
Know key Zero Trust technologies: mTLS, SPIFFE/SPIRE, BeyondCorp

What is this? (Beginner On-Ramp)

Zero Trust is a modern security philosophy. The old model assumed anyone on the inside of the corporate network was safe. Zero Trust assumes the network is already compromised, requiring every user and device to strictly prove their identity for every single action.

32.1 Why Perimeter Security Failed

    The Old Model: Castle and Moat
    ────────────────────────────────

    Internet → Firewall → TRUSTED INTERNAL NETWORK
                          "If you're inside, you're trusted"

    Problems:
    1. Lateral movement: Attacker compromises one machine
       → Has access to EVERYTHING on the internal network
       → Famous: Target breach (2013) — HVAC vendor compromised
                  → internal network access → POS systems → 40M cards

    2. Insider threats: Malicious or compromised employee
       → Already inside the perimeter
       → Traditional security provides no protection

    3. Cloud and remote work: The perimeter dissolved
       → Employees on home networks, coffee shops
       → Applications in multiple cloud providers
       → "Inside" the network is meaningless

    Zero Trust Principle:
    ──────────────────────
    "Never Trust, Always Verify"
    → Trust no network, no device, no user by default
    → Verify explicitly for every request
    → Assume breach: limit blast radius

32.2 Zero Trust Core Principles

    Zero Trust Pillars
    ───────────────────

    1. VERIFY EXPLICITLY:
       • Authenticate and authorize every request
       • Use multiple signals: identity, device health, location, risk score
       • Not just at login — continuous verification

    2. LEAST PRIVILEGE ACCESS:
       • Just-in-time (JIT) access: grant when needed, revoke after
       • Just-enough access: only what's needed for the task
       • No standing admin access

    3. ASSUME BREACH:
       • Segment everything (micro-segmentation)
       • Encrypt all traffic (even internal)
       • Monitor everything (assume attacker is already inside)
       • Minimize blast radius

    Architecture Components:
    ──────────────────────────
    Identity Provider (IdP): Authenticate users and services
    Policy Engine: Authorize access based on context
    Policy Enforcement Points (PEPs): Enforce at every request
    Device Trust: Verify device health before granting access
    Micro-segmentation: Network isolation at workload level

32.3 Zero Trust Implementation

    Zero Trust Data Flow
    ─────────────────────

    User/Service wants to access Resource
           │
           ▼
    ┌─────────────────────────────────────────────────────────┐
    │  Policy Enforcement Point (PEP) — e.g. API Gateway,    │
    │  Service Mesh, IAP                                       │
    └───────────────────────┬─────────────────────────────────┘
                            │ Request metadata:
                            │ • Identity (JWT/certificate)
                            │ • Device posture
                            │ • Source IP/location
                            │ • Time of day
                            │ • Resource being accessed
                            ▼
    ┌─────────────────────────────────────────────────────────┐
    │  Policy Decision Point (PDP) — OPA, IAM                │
    │                                                          │
    │  ALLOW if:                                               │
    │  • identity is authenticated                            │
    │  • device has current patches                           │
    │  • user has role for this resource                      │
    │  • within allowed hours                                 │
    │  • risk score acceptable                                │
    └───────────────────────┬─────────────────────────────────┘
                            │
                      ALLOW or DENY

32.4 Service-to-Service: SPIFFE/SPIRE

SPIFFE (Secure Production Identity Framework For Everyone) provides workload identity for Zero Trust service-to-service authentication.

    SPIFFE Architecture
    ────────────────────

    Every workload gets a SPIFFE ID:
    spiffe://trust-domain/path
    e.g.: spiffe://example.com/ns/production/sa/checkout-service

    SPIRE (SPIFFE Runtime Environment) issues SVIDs (SPIFFE Verifiable Identity Documents):
    • X.509 SVID: Short-lived TLS certificate (1 hour)
    • JWT SVID: Short-lived JWT token

    How it works:
    ─────────────
    1. checkout-service starts
    2. SPIRE Agent (on node) attests the workload (verifies via k8s API)
    3. Agent issues X.509 SVID to checkout-service
    4. checkout-service calls payment-service using its SVID
    5. payment-service verifies the certificate's SPIFFE ID
    6. Both authenticate — no passwords, no keys to manage!

    Result: mTLS with auto-rotating certificates
    across your entire service mesh

32.5 Google BeyondCorp Model

    BeyondCorp: No Privileged Network
    ───────────────────────────────────

    Traditional VPN model:
    Remote worker → VPN → Internal network → All resources

    BeyondCorp model:
    Remote worker → Identity-Aware Proxy → Specific resource
    (No VPN, no "internal network" concept)

    Implementation components:
    1. Device Inventory: All devices enrolled and managed
    2. Device Trust: Device must have current OS, patches, certificates
    3. User Identity: Strong authentication (SSO + 2FA)
    4. Access Proxy: Route all access through IAP
       → Google: Cloud Identity-Aware Proxy (IAP)
       → Open source: Pomerium, Teleport

    Access decision uses:
    • Who: Identity (Google account + 2FA)
    • What device: Device trust score (MDM enrolled, patched)
    • From where: Location risk score
    → ALL THREE must pass to gain access

32.6 Zero Trust in Kubernetes

# Implementing Zero Trust in Kubernetes with Cilium

# 1. Default deny all (assume breach)
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  endpointSelector: {}      # Applies to all pods
  ingress: []               # No ingress allowed
  egress: []                # No egress allowed

---
# 2. Explicit allow with identity verification
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: checkout-to-payment-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
  # Only allow from checkout-service, verified via SPIFFE identity
  - fromEndpoints:
    - matchLabels:
        app: checkout-service
    toPorts:
    - ports:
      - port: "8081"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/api/v1/charge"   # Only specific endpoint!

32.7 Interview Questions

Q1: What is Zero Trust and what problem does it solve?

Answer: Zero Trust is a security model based on “Never trust, always verify” — no user, device, or network is trusted by default, regardless of whether they’re inside or outside the network perimeter. It solves the perimeter security problem: traditional security assumed that once inside the corporate network, you could be trusted. With cloud computing, remote work, and sophisticated attackers, the perimeter has dissolved. Attackers who compromise one machine inside the network have lateral movement to all other internal resources. Zero Trust eliminates this by authenticating and authorizing every request individually, encrypting all traffic (even internal), and micro-segmenting workloads so a breach of one service doesn’t give access to others.

32.8 Summary

Concept	Implementation
Verify Explicitly	mTLS, SPIFFE/SPIRE, IAP
Least Privilege	JIT access, OPA, IAM
Assume Breach	Micro-segmentation, NetworkPolicy
Device Trust	MDM, device certificates
BeyondCorp	No VPN, identity-aware proxy

Next Chapter: Chapter 33: PKI, TLS, mTLS & Certificate Management

Prerequisites

Networking basics.

Deep Dive: VPN Architectures (WireGuard vs OpenVPN)

While Zero Trust aims to eliminate VPNs, they remain a foundational piece of infrastructure for site-to-site connectivity and legacy access.

OpenVPN

The traditional standard. It operates in user-space, making it highly flexible but slower due to context switching between kernel and user space. It supports TCP and UDP and has massive ecosystem support.

WireGuard

The modern standard. WireGuard is integrated directly into the Linux kernel (as of 5.6).

Performance: Because it runs in kernel-space, it is drastically faster than OpenVPN with much lower latency.
Codebase: It consists of ~4,000 lines of code compared to OpenVPN’s ~100,000, drastically reducing the attack surface.
Cryptography: It uses modern, fixed cryptographic primitives (Noise protocol framework, ChaCha20, Poly1305) rather than allowing cipher negotiation, preventing downgrade attacks.

Production Note: For modern deployments, WireGuard is almost always preferred unless you have a strict compliance requirement forcing legacy IPsec or you need to tunnel over TCP (which WireGuard does not support natively).

Advantages & Disadvantages

Advantages: Highly resilient against internal lateral movement, perfect for remote workforces. Disadvantages: Expensive and complex to retrofit into legacy networks.

Common Mistakes

Treating the corporate VPN as a trusted zone.
Implementing Zero Trust only at the network level, ignoring device posture and user identity.

Troubleshooting

Symptom	Cause	Diagnosis	Fix
User cannot access internal app	Device posture check failed or missing mTLS cert	`Check Identity Provider (IdP) logs`	Ensure device is managed and compliant; verify cert issuance

Hands-on Lab

Objective: Understand identity-aware proxying.

# 1. Test unauthenticated access (should fail)
curl -I https://internal-app.example.com

# 2. Test authenticated access (mocked)
curl -H "Authorization: Bearer <token>" -I https://internal-app.example.com

Exercises

Describe how a Zero Trust Architecture handles a scenario where an employee’s laptop is compromised while connected to the corporate network.
Compare a traditional VPN approach with an Identity-Aware Proxy (IAP) approach.

Revision Notes

Zero Trust Principle: Never trust, always verify.
Identity is the new perimeter, replacing the network firewall.
Continuous authentication and authorization are required for every request.