Zero Trust Architecture: A Developer's Guide#

The traditional security model — a strong perimeter with a trusted internal network — is dead. VPNs don't protect against compromised internal services, lateral movement, or insider threats.

Zero trust flips the model: never trust, always verify. Every request is authenticated and authorized, regardless of where it comes from.

Traditional vs Zero Trust#

Perimeter security (old):

Internet → Firewall → Trusted Internal Network
                          (everything trusts everything)

If an attacker gets past the firewall, they own the network.

Zero trust (new):

Every request → Authenticate → Authorize → Encrypt → Allow
                 (who are you?) (can you do this?) (mTLS)

No implicit trust. Every service verifies every request.

Core Principles#

1. Verify Explicitly#

Authenticate and authorize every request based on all available data:

• User identity (JWT, certificate)
• Device health (is the device managed? patched?)
• Network location (is this from an expected IP?)
• Request context (time, behavior patterns)

2. Least Privilege Access#

Grant the minimum permissions needed:

• Service A can only call Service B's /api/users endpoint, not all endpoints
• Database credentials are scoped per service (not a shared admin password)
• Permissions are time-bounded where possible

3. Assume Breach#

Design as if the attacker is already inside:

• Encrypt all traffic (even internal)
• Log everything for forensics
• Segment networks (blast radius containment)
• Monitor for anomalies

Implementation Patterns#

mTLS (Mutual TLS)#

Both client and server present certificates:

Service A → presents certificate → Service B verifies
Service B → presents certificate → Service A verifies
         ← encrypted connection established →

No more trusting the network. Even if an attacker is on the same network, they can't impersonate a service without its certificate.

Tools: Istio (auto mTLS), Linkerd, SPIFFE/SPIRE, Cloudflare Tunnel

Identity-Based Access#

Replace IP-based firewall rules with identity-based policies:

# Old: IP-based
allow 10.0.1.0/24 → 10.0.2.0/24:5432

# New: Identity-based
allow service:order-service → service:database role:read
allow service:admin-service → service:database role:admin

Tools: SPIFFE (identity framework), Open Policy Agent (OPA), AWS IAM roles

Microsegmentation#

Break the network into small segments. Each service only communicates with explicitly allowed peers:

┌─────────────┐     ┌─────────────┐
│ API Service │ ──→ │ User Service│
│             │  ✗  │             │
│             │ ──→ │Order Service│
└─────────────┘     └─────────────┘
                         ✗ (blocked)
                    ┌─────────────┐
                    │Payment Svc  │
                    └─────────────┘

Only explicitly allowed paths work. Everything else is denied by default.

Tools: Kubernetes NetworkPolicy, Calico, Cilium, AWS Security Groups

BeyondCorp (Google's Model)#

Google's implementation of zero trust for employee access:

Employee → Device check (managed, patched?)
         → Identity check (SSO, MFA)
         → Context check (location, time, behavior)
         → Access proxy → Internal app

No VPN needed. Access decisions are continuous, not one-time.

Tools: Google BeyondCorp, Cloudflare Access, Zscaler, Tailscale

Zero Trust for Microservices#

Service-to-Service Authentication#

Order Service → JWT with service identity → API Gateway
             → mTLS certificate → Payment Service
             → IAM role assumption → AWS S3

Every hop is authenticated. No service trusts another just because they're on the same network.

Request-Level Authorization#

Payment Service receives: POST /charge
  → Verify JWT signature ✓
  → Check: is caller "order-service"? ✓
  → Check: does order-service have "payments:write" scope? ✓
  → Check: is request amount within policy limits? ✓
  → Process payment

OPA (Open Policy Agent) lets you write authorization policies as code:

allow {
  input.caller == "order-service"
  input.action == "charge"
  input.amount < 10000
}

Secrets Management#

Never hardcode secrets. Use dynamic, short-lived credentials:

Service starts → requests credentials from Vault
Vault → generates database password (TTL: 1 hour)
Service → uses password → password expires → request new one

Tools: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager

Architecture Example#

Zero Trust Microservices#

Client → Cloudflare Access (identity check + device trust)
       → API Gateway (JWT validation, rate limiting)
           → Service Mesh (Istio)
               → Service A ←mTLS→ Service B
               → Service B ←mTLS→ Database
               → Service C ←mTLS→ Message Queue

Cross-cutting:
  → OPA (authorization policies)
  → Vault (secrets management)
  → SPIRE (identity certificates)
  → Falco (runtime threat detection)

Generate a zero trust architecture →

Getting Started#

Phase 1: Foundation#

• Enable mTLS between all services (Istio/Linkerd makes this easy)
• Move secrets to Vault or cloud secrets manager
• Add JWT validation at the API gateway

Phase 2: Identity#

• Implement SPIFFE identities for all services
• Replace IP-based rules with identity-based policies
• Add OPA for fine-grained authorization

Phase 3: Continuous Verification#

• Monitor all service-to-service traffic
• Implement anomaly detection (unusual call patterns)
• Add device trust for human access (BeyondCorp model)

Common Mistakes#

1. Treating zero trust as a product — it's an architecture, not a tool you buy
2. Skipping mTLS — if internal traffic is unencrypted, zero trust is theater
3. Shared database credentials — each service needs its own scoped credentials
4. VPN = zero trust — VPNs give network access, not zero trust
5. All-or-nothing — implement incrementally, starting with the most sensitive services

Summary#

---

Audit your architecture's security at codelit.io — OWASP security checks, compliance reports, and vulnerability scans on any diagram.