Zero Trust Architecture Guide -- BeyondCorp, Microsegmentation & Continuous Verification
Zero Trust architecture eliminates implicit trust based on network location -- requiring continuous verification of every user, device, and request regardless of whether it originates inside or outside the corporate perimeter.
What You'll Learn
You will learn to design a Zero Trust architecture using Google BeyondCorp principles, implement microsegmentation with Kubernetes network policies, deploy identity-aware proxies, and build continuous verification pipelines.
Why It Matters
The traditional perimeter model assumes everything inside the corporate network is trusted. With cloud adoption, remote work, and insider threats, that assumption is broken. Zero Trust reduces breach impact by 80% and is mandated by Executive Order 14028 for US federal agencies.
Real-World Use
A SaaS company with 100% remote workforce implements Zero Trust using Cloudflare Access for identity-aware proxying and Tailscale for mesh VPN, eliminating VPN server management and reducing network attack surface to zero public-facing services.
Zero Trust Models Compared
| Model | Vendor | Approach | Key Component | Best For |
|---|---|---|---|---|
| BeyondCorp | Identity-aware proxy | Access Proxy, Device Inventory | Cloud-native, Google Workspace | |
| ZTNA | Cloudflare, Zscaler | Cloud-delivered edge | Reverse proxy, Browser isolation | Remote workforce |
| Zero Trust Networking | Tailscale, Twingate | Mesh overlay | WireGuard-based mesh, per-app ACL | Distributed teams, homelab |
| Microsegmentation | Illumio, VMware | Host-based firewall | Label-based policy, agent | Data center, hybrid cloud |
| Identity-Aware Proxy | GCP, Cloudflare | Request-level auth | Context-aware access | GCP applications |
BeyondCorp-Inspired Architecture
graph TD
subgraph "User Device"
A[User] --> B[Device Agent]
B --> C[Mutual TLS to IAP]
end
subgraph "Zero Trust Control Plane"
C --> D[Identity-Aware Proxy]
D --> E[Policy Engine]
E --> F[Device Inventory]
E --> G[Identity Provider]
E --> H[Context Database]
end
subgraph "Trusted Application Infrastructure"
D --> I[Application Server]
I --> J[(Database)]
D --> K[API Gateway]
K --> L[(Internal Service)]
end
style A fill:#4a90d9,stroke:#fff,color:#fff
style D fill:#e74c3c,stroke:#fff,color:#fff
style E fill:#f39c12,stroke:#fff,color:#fff
style K fill:#27ae60,stroke:#fff,color:#fff
Identity-Aware Proxy Configuration
# Cloudflare Access identity-aware proxy policy
resource "cloudflare_access_application" "internal_apps" {
zone_id = var.cloudflare_zone_id
name = "Internal Applications"
domain = "internal.dodatech.com"
session_duration = "24h"
allowed_idps = ["dodatech-okta"]
policies {
name = "Engineering Access"
decision = "allow"
include {
email_domain = ["dodatech.com"]
}
require {
okta_groups = ["engineering", "security", "sre"]
}
require {
device_posture = ["device-posture-rule"]
}
}
}
# Device posture rule -- require macOS 14+ with disk encryption
resource "cloudflare_device_posture_rule" "macos_secure" {
name = "macOS Secure"
type = "os_version"
match = "greater_or_equal"
value = "14.0"
os = "mac"
description = "Requires macOS 14+"
}
# Additional rule for disk encryption
resource "cloudflare_device_posture_rule" "disk_encryption" {
name = "Disk Encryption Enabled"
type = "disk_encrypted"
os = "mac"
description = "Requires full disk encryption"
}
Expected behavior: All requests to internal.dodatech.com pass through Cloudflare Access. The proxy verifies the user's identity via Okta, checks device posture (OS version, disk encryption), and enforces group membership before allowing access. No VPN is required.
Kubernetes Network Microsegmentation
# Calico network policy for Zero Trust microsegmentation
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: app-tier-isolation
namespace: production
spec:
selector: app == "payment-service"
ingress:
- action: Allow
protocol: TCP
source:
selector: app == "api-gateway"
destination:
ports:
- 8080
- action: Allow
protocol: TCP
source:
selector: app == "health-checker"
destination:
ports:
- 8080
egress:
- action: Allow
protocol: TCP
destination:
selector: app == "database"
ports:
- 5432
- action: Allow
protocol: TCP
destination:
selector: app == "cache"
ports:
- 6379
- action: Allow
protocol: UDP
destination:
selector: app == "dns"
ports:
- 53
---
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: default-deny-all
spec:
selector: all()
ingress:
- action: Deny
egress:
- action: Deny
types:
- Ingress
- Egress
Expected behavior: The payment-service pod accepts traffic only from the api-gateway and health-checker. It can connect only to the database and cache. All other traffic is denied by the default-deny global policy. This prevents lateral movement if a pod is compromised.
Continuous Verification with Policy Engine
"""Real-time access policy evaluation for Zero Trust."""
import json
import hashlib
from datetime import datetime
class PolicyEvaluator:
def __init__(self):
self.policy_cache = {}
self.max_users_per_ip = 3
self.max_sessions_per_user = 5
def evaluate_request(self, request):
"""Evaluate a single access request against zero trust policies."""
score = 0
reasons = []
# Identity verification
if not request.get("jwt"):
return {"decision": "DENY", "reason": "No authentication token"}
# Device posture check
device = request.get("device", {})
if device.get("os_version", "0") < "14.0":
score -= 20
reasons.append("Outdated OS version")
if not device.get("disk_encrypted", False):
score -= 30
reasons.append("Disk encryption not enabled")
if not device.get("firewall_enabled", False):
score -= 10
reasons.append("Firewall not active")
# Behavioral anomalies
user_profile = self._get_user_profile(request.get("user_id"))
current_ip = request.get("source_ip")
if user_profile.get("typical_ips") and current_ip not in user_profile["typical_ips"]:
score -= 15
reasons.append(f"Unusual source IP: {current_ip}")
if user_profile.get("typical_geo") and \
request.get("geo") not in user_profile["typical_geo"]:
score -= 20
reasons.append(f"Unusual geo: {request.get('geo')}")
# Resource sensitivity
resource_sensitivity = request.get("resource_sensitivity", "low")
if resource_sensitivity == "high" and score < 50:
return {"decision": "DENY", "reason": "Risk score too low for high-sensitivity resource",
"score": score, "details": reasons}
if resource_sensitivity == "critical" and score < 80:
return {"decision": "DENY", "reason": "Insufficient trust for critical resource",
"score": score, "details": reasons}
if score >= 50:
return {"decision": "ALLOW", "score": score, "details": reasons}
else:
return {"decision": "DENY", "score": score, "reason": "Risk score below threshold",
"details": reasons}
def _get_user_profile(self, user_id):
profiles = {
"user-123": {
"typical_ips": ["203.0.113.0/24"],
"typical_geo": ["US-NY"]
}
}
return profiles.get(user_id, {})
# Usage
request = {
"user_id": "user-123",
"jwt": "valid-token",
"source_ip": "198.51.100.5",
"geo": "US-CA",
"resource_sensitivity": "high",
"device": {
"os_version": "14.5",
"disk_encrypted": True,
"firewall_enabled": True
}
}
evaluator = PolicyEvaluator()
result = evaluator.evaluate_request(request)
print(json.dumps(result, indent=2))
# Expected output:
# {
# "decision": "DENY",
# "score": 65,
# "reason": "Unusual geo: US-CA",
# "details": ["Unusual source IP: 198.51.100.5", "Unusual geo: US-CA"]
# }
Expected behavior: The policy engine computes a risk score based on identity, device health, and behavioral context. A request from an unusual geo with a user who typically connects from New York triggers a deny decision despite valid credentials and a healthy device.
WireGuard Mesh VPN for Zero Trust Networking
# Tailscale-like mesh VPN node configuration
[Interface]
PrivateKey = <node-private-key>
Address = 100.100.0.1/32
DNS = 100.100.0.1
# ACL: only allow SSH and HTTPS to specific nodes
[Peer]
# Application server
PublicKey = <app-server-public-key>
AllowedIPs = 100.100.0.10/32
# Only SSH and HTTPS ports allowed at the firewall level
[Peer]
# Database server
PublicKey = <db-server-public-key>
AllowedIPs = 100.100.0.20/32
# Only PostgreSQL port allowed
[Peer]
# Monitoring server
PublicKey = <monitoring-public-key>
AllowedIPs = 0.0.0.0/0 # Full access for monitoring only
Expected behavior: Each node has a unique WireGuard IP in the 100.100.x.x range. ACLs determine which IPs each node can reach. An application server can connect only to the database server on port 5432 and the monitoring server. No node can reach the internet through the mesh.
Google Cloud IAP Configuration
# Enable Identity-Aware Proxy on GCP
gcloud services enable iap.googleapis.com
# Create OAuth consent screen
gcloud alpha iap oauth-clients create \
projects/$PROJECT_ID/brands/$BRAND_ID \
--display-name="DodaTech IAP Client"
# Configure IAP on App Engine
gcloud iap web enable \
--resource-type=app-engine \
--service=default \
--oauth2-client-id=$CLIENT_ID \
--oauth2-client-secret=$CLIENT_SECRET
# Set access policy to allow only specific groups
gcloud iap web add-iam-policy-binding \
--resource-type=app-engine \
--service=default \
--member="group:engineering@dodatech.com" \
--role="roles/iap.httpsResourceAccessor"
# Expected output:
# Updated IAM policy for appEngineService.
# Binding members:
# group:engineering@dodatech.com: roles/iap.httpsResourceAccessor
Expected behavior: IAP wraps the App Engine service with Google authentication. Only authenticated users in the engineering group can access the application. All access attempts are logged to Cloud Audit Logs with user identity and request details.
Common Errors
Treating Zero Trust as a product rather than a strategy -- Buying a ZTNA solution does not make your organization Zero Trust. It requires changes to network architecture, identity management, device management, and organizational culture.
Flat network with no microsegmentation -- Once inside the network, attackers can move laterally. Zero Trust requires per-application, per-environment network policies that default-deny all traffic and allow only explicit connections.
Not verifying device posture before granting access -- A compromised device with valid user credentials can exfiltrate data. Verify OS patch level, disk encryption, firewall status, and antivirus health before granting access to sensitive resources.
Standing privileges instead of just-in-time access -- Users with permanent admin access violate Zero Trust principles. Implement JIT privilege elevation with expiry, approval workflows, and session recording for all privileged actions.
Ignoring the human factor -- Zero Trust policies that block every unusual action frustrate users and create shadow IT. Balance security with productivity by implementing progressive verification: step up authentication for higher-risk actions rather than blocking outright.
Practice Questions
What is the fundamental difference between perimeter security and Zero Trust? Perimeter security trusts everything inside the corporate network. Zero Trust trusts nothing by default, regardless of network location. Zero Trust verifies every request based on identity, device, context, and policy before granting access.
How does microsegmentation prevent lateral movement? Microsegmentation divides the network into isolated segments with per-service firewall rules. A compromised web server can communicate only with its database (port 5432) and cache (port 6379). It cannot reach other servers, limiting the blast radius of a breach.
What role does device posture play in Zero Trust decisions? Device posture ensures that only healthy, compliant devices can access resources. A device with outdated patches, disabled encryption, or missing antivirus is considered untrusted even if the user's credentials are valid.
Why is continuous verification important rather than just authentication at login? User context changes after login: a user authenticates from the office but their session is then used from a different country. Continuous verification re-evaluates risk at each request, detecting session hijacking, insider threats, and compromised credentials in real time.
Challenge: Design a Zero Trust architecture for a three-tier web application (load balancer, application server, database) in a cloud environment. Specify the identity provider, device posture requirements, network policies, and access proxy configuration. Implement a Kubernetes network policy that restricts the app server to only talk to the database on port 5432.
Mini Project
Build a Zero Trust lab environment. Deploy WireGuard mesh VPN on three cloud VMs (app, db, monitoring) with strict ACLs limiting inter-node communication. Set up Cloudflare Access or NGINX with mTLS as an identity-aware proxy. Configure Kubernetes network policies using Calico that enforce microsegmentation. Write a policy evaluator in Python that verifies device posture before allowing access to the app tier.
Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro