← Back to Home
🔒

Zero Trust Demo Lab

A hands-on demo environment for Cloudflare Zero Trust — a clean BYOD device enrolled via WARP, Gateway enforcing identity-aware SWG policies, and Cloudflare Access protecting a live Workers application. No VPN. No firewall exceptions.

Live
WARP Gateway Access GCP Workers

The Problem

Demoing Zero Trust to customers requires showing the full onboarding flow — a fresh, unmanaged device enrolling via WARP for the first time. Corporate laptops already have managed WARP enrolled through MDM. You can't re-enroll or alter the configuration without affecting your actual work setup.

The standard workaround — screensharing a pre-configured environment or walking through static screenshots — doesn't land the same way as a live demo. Customers want to see real policy enforcement, real traffic flowing through Gateway, and real Access auth happening in a browser they're watching.

What I Built

A GCP e2-small VM running Ubuntu 22.04, treated as a clean BYOD device. The WARP client is installed and enrolled into a personal Cloudflare Zero Trust organization — replicating exactly what an employee on a personal laptop would experience.

Gateway DNS and HTTP policies are configured to enforce identity-aware filtering: category-based DNS blocks, HTTP inspection with user identity tied to the enrolled device, and real-time traffic visible in the Activity Log. Cloudflare Access protects a live Workers application — unauthenticated requests are intercepted, the user authenticates via Cloudflare's identity provider, and access is granted based on policy.

The full demo runs as a single connected story: a BYOD device enrolls, all traffic is inspected by SWG, and when the user needs to reach an internal application, Access handles auth with no VPN and no firewall rule changes required.

Architecture

GCP VM (Ubuntu 22.04, e2-small)
  └── WARP client enrolled → Cloudflare Zero Trust org
        │
        ▼
Cloudflare Edge
  ├── Gateway — DNS Policy
  │     └── Category blocks (e.g. Games, Social Media)
  │           → NXDOMAIN returned, block page shown
  │
  ├── Gateway — HTTP Policy
  │     └── Identity-aware rules tied to enrolled device
  │           → User email visible in Activity Log
  │
  └── Access — Self-hosted Application
        └── Workers app (se-intel.macksportreport.com)
              ├── Unauthenticated request intercepted
              ├── Redirect → Cloudflare login
              ├── Identity verified → policy evaluated
              └── Granted → app loads in browser

Demo Flow

The demo runs as a single narrative across four products — no context switching between dashboards mid-call:

  • • Enrollment — WARP connects on the VM. The device appears instantly in Zero Trust → My Team → Devices. No MDM, no IT ticket, no waiting.
  • • SWG in action — Browse to a blocked category. DNS policy returns NXDOMAIN, Gateway block page loads. Switch to the Activity Log — the request is there with the user's identity attached.
  • • Identity-aware HTTP — Every outbound request shows the enrolled user's email in Gateway HTTP logs. Policy can be written against identity, not just IP.
  • • ZTNA — Navigate to the protected Workers app. Access intercepts, prompts for login, grants access. No VPN tunnel, no firewall change — the app is never exposed to the public internet.

Cloudflare Products Used

WARP Client — Enrolls the GCP VM into the Zero Trust organization. All device traffic is tunneled through Cloudflare's edge — DNS and HTTP both inspected by Gateway.

Gateway (DNS) — Category-based DNS policies block entire content categories. Requests to blocked domains return NXDOMAIN and surface a customizable block page.

Gateway (HTTP) — Identity-aware HTTP inspection. Every proxied request carries the enrolled user's identity — policies can be written against email, group membership, device posture, and more.

Cloudflare Access — Self-hosted application protecting a Workers app. Unauthenticated requests are intercepted at the edge, never reaching the origin. Auth is handled entirely by Cloudflare — no SDK changes required in the application.

Workers — The protected application itself, deployed to Cloudflare's edge. Placed behind Access without any code changes — Access operates at the network layer.

Why I Built This