Zero Trust Networking

How It Works

Zero trust networking is built on one axiom: the network is always compromised. Every request — whether it originates from a corporate office, a coffee shop, or another microservice in the same data center — must prove its identity and be authorized before accessing any resource. There is no "inside" and "outside." There is only verified and unverified.

This is a fundamental departure from the perimeter model that dominated networking for decades. In the traditional model, a castle wall (firewall, VPN) surrounds the network, and everything inside the wall is trusted. The problem is obvious in hindsight: once an attacker gets inside (and they always do — phishing, stolen credentials, compromised dependencies), they have unrestricted lateral movement. The 2020 SolarWinds attack demonstrated this catastrophically: attackers compromised a software update, got inside the perimeter of 18,000 organizations including multiple U.S. government agencies, and moved freely through internal networks.

The Three Pillars of Zero Trust

1. Identity is the New Perimeter

In zero trust, identity replaces IP addresses as the fundamental security primitive. Instead of firewall rules like "allow 10.0.1.0/24 to access 10.0.2.0/24," policies read "the checkout-service workload can call the payment-service API" or "employees in the engineering group with a compliant device can access the production dashboard."

For users, identity comes from an Identity Provider (IdP) — Okta, Azure AD, Google Workspace. Authentication produces a cryptographic token (JWT via OIDC) that travels with every request.

For workloads (services, containers, serverless functions), identity comes from platforms like SPIFFE (Secure Production Identity Framework for Everyone). Each workload gets a SPIFFE Verifiable Identity Document (SVID) — an X.509 certificate that cryptographically proves its identity. Service meshes like Istio and Linkerd use SPIFFE under the hood for mTLS.

# SPIFFE ID format — identity tied to workload, not network
spiffe://cluster.example.com/ns/production/sa/payment-service

# NOT this — IP-based identity is fragile
10.0.2.47:8080  # What if the pod restarts on a different IP?

2. Continuous Verification

Traditional auth checks identity once at login and trusts the session for hours or days. Zero trust verifies every request. This does not mean the user enters their password for every API call — it means the system continuously evaluates:

• Is this token still valid (not expired, not revoked)?
• Has the user's risk level changed (impossible travel, anomalous behavior)?
• Is the device still compliant (disk encrypted, OS patched, no malware detected)?
• Does this specific request match the user's authorization (right resource, right action)?

If any signal changes mid-session, access is revoked or stepped up (require MFA again). Microsoft calls this "Conditional Access" — access conditions are evaluated dynamically, not just at the authentication moment.

3. Least Privilege and Micro-Segmentation

Every identity gets the minimum access required to perform its function. This applies at two levels:

• Application layer: APIs enforce fine-grained permissions. The inventory-service can read product data but cannot modify orders.
• Network layer: Micro-segmentation ensures services can only communicate with explicitly authorized peers. Even if an attacker compromises the inventory-service, they cannot reach the payment-service because no network path is authorized.

In Kubernetes, this translates to NetworkPolicies (or Cilium's CiliumNetworkPolicy) that default-deny all traffic and explicitly allow only the edges in the service dependency graph.

# Kubernetes NetworkPolicy — default deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

---
# Allow only checkout-service to call payment-service
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-checkout-to-payment
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: payment-service
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: checkout-service
      ports:
        - port: 8080

The Google BeyondCorp Model

Google's BeyondCorp is the blueprint that made zero trust practical at scale. After the 2009 Operation Aurora attack (where Chinese state actors breached Google's corporate network), Google made a radical decision: eliminate the corporate VPN entirely. Every internal application would be accessible from any network — the internet, the office, or a home Wi-Fi — through the same path.

The architecture:

1. Access Proxy: Every internal application sits behind an identity-aware proxy (Google's is called the Identity-Aware Proxy, or IAP). There is no direct network path to any internal service.
2. User + Device Identity: Every request carries a user identity (Google SSO) and a device certificate. The device certificate is provisioned to managed devices and attests to the device's security posture.
3. Access Control Engine: For every request, the engine evaluates: Who is the user? What is their role? What device are they on? Is the device compliant? What resource are they accessing? What is the current threat level?
4. Trust Tiers: Instead of binary allow/deny, BeyondCorp assigns trust levels. A fully managed, encrypted laptop from the corporate office gets high trust. An unmanaged phone on public Wi-Fi gets low trust. Different resources require different trust tiers.

The result: Google employees access internal tools from anywhere without a VPN. The office network has no special privileges. An attacker who compromises the office Wi-Fi gains nothing because every application still requires identity verification.

Implementing Zero Trust: A Practical Roadmap

Zero trust is not a product installed on a Tuesday afternoon. It is an architecture adopted incrementally over months or years. Here is a pragmatic sequence:

Phase 1 — Identity-Aware Application Access (Months 1-3)

Replace VPN-based access to internal web applications with an identity-aware proxy. Tools like Cloudflare Access, Tailscale, or Google IAP sit in front of internal apps and require SSO authentication for every request.

Before:  User → VPN → Corporate Network → Internal App
After:   User → Cloudflare Access (SSO check) → Internal App

This single change eliminates the biggest attack vector: VPN credentials granting network-wide access. Now a stolen credential only accesses the specific apps that user is authorized for.

Phase 2 — Service-to-Service mTLS (Months 3-6)

Deploy a service mesh (Linkerd, Istio) or use SPIFFE/SPIRE to give every workload a cryptographic identity. Enable mTLS so all east-west traffic is authenticated and encrypted. Add authorization policies so services can only call their declared dependencies.

Phase 3 — Device Posture and Continuous Verification (Months 6-12)

Integrate device management (Intune, Jamf, CrowdStrike) into access decisions. Require disk encryption, OS patches, and endpoint protection as conditions for access. Implement session re-evaluation so that if a device becomes non-compliant, active sessions are terminated.

Phase 4 — Full Micro-Segmentation (Months 12-18)

Default-deny all network traffic. Build an explicit allowlist of service-to-service communication. Monitor for unauthorized connection attempts. This is the hardest phase because it requires a complete service dependency map and breaks anything not explicitly allowed.

Zero Trust in System Design Interviews

Zero trust comes up in system design interviews when discussing security architecture. The key points to hit:

1. Why perimeter security fails: Assume the network is compromised. Single breach = full lateral movement.
2. Identity over IP: Use cryptographic identity (mTLS, JWTs) not network location.
3. Defense in depth: Authentication at the edge, authorization at each service, encryption everywhere.
4. Blast radius reduction: Micro-segmentation limits what a compromised service can reach.

A common interview question: "How would an engineer secure communication between microservices?" The zero trust answer: deploy a service mesh for automatic mTLS with SPIFFE identities, add authorization policies at each service, default-deny all network traffic with NetworkPolicies, and log every access decision for audit. This is dramatically stronger than the naive answer of "put them in a private subnet."