Skip to content

Zero Trust Architecture Guide -- BeyondCorp, Microsegmentation & Continuous Verification

DodaTech Updated 2026-06-22 9 min read

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 Google 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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