Cloudflare Zero Trust & SASE - Capstone Lab

Zero Trust PS Bootcamp: Individually Auto-Graded Capstone. This is a single full-day lab. You stand up the entire Cloudflare One (SASE) posture for a customer that is still running on flat network trust, then a grader re-reads your live Zero Trust configuration and re-runs the enforcement checks to score all 16 deliverables.

Before You Begin: Install Terraform & Create Your API Tokens

Two setup steps before the scenario. Phase 7 provisions your log sink with Terraform, which is not preinstalled on the lab workstations, and several steps need API tokens. Do both now so nothing blocks you later.

1. Install Terraform

Run this once on the Ubuntu server in your pod - it is a single binary, and that box is where you pull logs from anyway. Copy the whole line:

sudo apt-get update -qq && sudo apt-get install -y -qq unzip curl && curl -fsSL https://releases.hashicorp.com/terraform/1.9.8/terraform_1.9.8_linux_amd64.zip -o /tmp/terraform.zip && sudo unzip -o /tmp/terraform.zip -d /usr/local/bin && terraform version

2. Create your API tokens

You need two tokens. Create both now at Cloudflare dashboard → User menu (top-right) → Profile → API Tokens → Create Token (dash.cloudflare.com/profile/api-tokens).

Create the build token (step by step)

The build token is the only credential in this capstone that can change your account, so create it by hand with exactly these four permissions - nothing more.

The four permissions to add in step 5 (all under the Account group):

3. Add your account ID

Paste your account ID below. The Terraform commands in this guide use it alongside the build token you saved above. The build token is held in this browser tab only and clears when you close it; the account ID is saved to this browser. Nothing is sent anywhere.

The AcmeCorp Brief

You are the incoming SASE lead for AcmeCorp. Your mandate is to stand up Cloudflare One, close the breach path the contractor's laptop opened, and decommission the flat VPN before the audit closes. The audit maps four demands to NIST 800-207, and the 16 deliverables below are how you satisfy them:

Work top to bottom. Each phase assumes the ones before it: you establish device trust, publish the app through a tunnel, put identity in front of it, control every byte at the Gateway, stop the data exfil with DLP, then seal the flat path so none of it can be bypassed.

Your Environment

You build the entire posture in the Cloudflare Zero Trust dashboard from your own browser, exactly as you would for a real customer. Use the pod's Ubuntu origin for Terraform and the log sink, and its enrolled Windows workstation for the grading command: the device-side checks depend on evidence only an enrolled device can produce (the Gateway DNS block page, the DLP upload block, the admin-box segmentation, and the breach-path seal). That box has curl.exe available in PowerShell; the Cloudflare One client is not pre-installed - you download, install, and enroll it yourself in 1.2 (do not use any consumer "Cloudflare WARP" app that may already be on the box).

How Grading Works

In the lab portal, select the Win11 client tab instead of Ubuntu origin, then open Windows PowerShell on the Win11 desktop.

When you are ready to be scored (or want to check progress), copy this command into that Win11 PowerShell window:

irm https://zt-capstone.cloudflareacademy.com/capstone | iex

The runner opens with a short "before you start" checklist of everything you will need - your course email, access code, a read-only API token, your domain, and the optional service-token and log-sink values - so you can gather them first. Then it walks you through four things:

You do not have to guess whether an item passes. Each phase below ends with a Verify block: copy-pasteable commands to self-check that phase from the enrolled workstation before you run the full grader.

Phase 0 - Recon

0.1 Inspect Starting Reachability

First, in the Ubuntu web terminal, confirm the billing service itself is running (the tunnel in Phase 2 will connect to localhost:8000):

curl -sS -o /dev/null -w 'billing-local %{http_code}\n' --connect-timeout 5 http://localhost:8000/

Then, on the pod's Windows workstation in PowerShell, try the private IP. This is a reachability observation, not a required pass:

curl.exe -sS -o NUL -w "billing-direct %{http_code}`n" --connect-timeout 5 http://<ubuntu-ip>:8000/
Test-NetConnection <ubuntu-ip> -Port 22 -InformationLevel Quiet

billing-direct 200 means Windows can reach the origin directly. billing-direct 000 means no HTTP response; before enrollment this may simply be a missing route between the Windows and Ubuntu networks, or the managed pod may already block inbound :8000. If billing-local is 200 but Windows gets 000, the billing service is running; proceed to Phase 1. If billing-local is also 000, check the billing service on Ubuntu before building its tunnel. The SSH test returns True only if a TCP connection to port 22 succeeds; an HTTP-code curl against an SSH port cannot establish that.

Now check whether the public billing hostname has been set up yet:

curl.exe -s -o NUL -w "billing.cf %{http_code}`n" https://billing.<your-domain>/

Phase 1 - Identity & Device Trust

1.1 Connect the Trusted SAML Server (identity) - required setup

Your pod's Zero Trust organization starts empty: no identity provider is connected, so the only login method is a one-time PIN. Before you can put identity in front of billing (Phase 3) or scope Gateway rules to a user, you must connect the shared lab identity provider, Trusted SAML Server. You do this exactly as you would for a real customer: register the IdP, hand Cloudflare its metadata, and test the round-trip.

Step 1 - Register your org on the lab SAML server. In your browser, go to https://labs.cloudflare.com/saml/register and register using your team name (the <team-name> part of <team-name>.cloudflareaccess.com, shown on the Account details card at Zero Trust → Overview, or under Settings → Team name and domain). This provisions a SAML application for your org on the shared authentik server and gives you a metadata XML download. Save that file - it contains the SSO URL, the issuer/entity ID, and the signing certificate.

Step 2 - Add the SAML provider in Cloudflare. In the Zero Trust dashboard go to Integrations → Identity providers → Add an identity provider → SAML. Then:

• Under Populate details with .xml file, upload the metadata file from Step 1. The Single sign-on URL, IdP Entity ID / Issuer URL, and Signing certificate fields auto-populate - do not hand-type them.
• Set Name to Trusted SAML Server.
• Under SAML attributes, click Add attribute and enter groups. This is what makes the Finance / IT group memberships available to your Access policies later - without it, a policy that includes the Finance group has nothing to match.
• Leave Email attribute name as email. Click Save.

Step 3 - Test the round-trip. Back on the Identity providers list, click Test next to Trusted SAML Server (it opens in a new tab). Log in as itadmin@acmecorp.com with password #Savetheinternet. You should land on a Cloudflare page reading "Your connection works!" showing the identity Access will use. If you instead see "Unable to find the requested identity provider" immediately after saving, wait a few seconds and reload - the provider is still propagating.

1.2 Install & enroll the Cloudflare One client - required setup

Your pod's Windows workstation is not enrolled yet - the managed pod ships greenfield. A device only produces trust signals (posture, WARP routing, Gateway enforcement) once it is running the Cloudflare One client and enrolled into your Zero Trust organization. Do this now, as itadmin@acmecorp.com, so the rest of Phase 1 has something to enforce on.

Step 1 - Permit enrollment. A greenfield org allows no enrollments by default. In the Zero Trust dashboard go to Team & Resources → Devices → Management tab → Device enrollment → Manage, add a policy whose rule includes Emails ending in @acmecorp.com with action Allow, and save. Without at least one enrollment policy the client login is rejected.

Step 2 - Download the Cloudflare One client. In the dashboard go to Settings → Resources → Downloads and under Download the Cloudflare One Client pick Windows (Download release, or Download beta for the newest build). You can also grab the Windows build directly from the Cloudflare One client beta-releases page. Do not use any pre-existing consumer "Cloudflare WARP" (1.1.1.1) app - it cannot log in to a Zero Trust team. Run the installer on the Windows workstation.

Step 3 - Enroll the device. Open the Cloudflare One client, go to its menu (gear / Preferences → Account) and choose Login with Cloudflare Zero Trust. Enter your team name (the <team-name> part of <team-name>.cloudflareaccess.com), then authenticate through the Trusted SAML Server as itadmin@acmecorp.com / #Savetheinternet. When it finishes the client status reads Connected and the device appears under Team & Resources → Devices → Your devices.

1.3 Enforce Device Health

The auditor's first finding is that unhealthy and unmanaged devices reach internal apps. Create a device posture check that proves a baseline of device health, and make it something a later Access or Gateway policy can require (it is not enough to define it; it has to be referenced so it actually gates something). Name the check AcmeCorp-Firewall-On and base it on the host firewall being enabled.

1.4 Fix the Split-Tunnel Reach

The workstation you just enrolled can authenticate, but internal resources are still unreachable over WARP, so people keep falling back to the VPN. This is the most common first-week mistake: the default WARP profile excludes the CGNAT range 100.64.0.0/10, which the internal overlay relies on, so traffic to it never enters the tunnel. Correct the device profile's split-tunnel configuration so the internal range is carried by WARP.

curl.exe -s https://www.cloudflare.com/cdn-cgi/trace | findstr /R "warp="

Phase 2 - Connectivity

2.1 Publish Billing Without Open Ports

Stand up (or reuse) the tunnel on the Linux server and add a public hostname route so billing.<your-domain> points at the local billing service http://localhost:8000. The result must be that the app is served through Cloudflare, not by hitting the origin IP.

nslookup billing.<your-domain>
curl.exe -s -o NUL -w "billing.cf %{http_code}`n" https://billing.<your-domain>/

Phase 3 - Access

3.1 Put Identity in Front of Billing

Create a self-hosted Access application named AcmeCorp-Billing for billing.<your-domain>, with a policy named Billing-Finance-Require. Finance is the only team that should reach billing, and the auditor requires that reaching it also proves device health and that the request comes through the managed client. Set a session short enough that a walk-away laptop re-authenticates within half an hour.

3.2 Let the Monitor Bot In

AcmeCorp runs an automated uptime monitor against billing that has no browser and no human to log in. Issue a service token for it and add a policy named Billing-Monitor-Token on the same app that admits requests presenting that token, without weakening the human policy.

Copy the Client ID and Client Secret when you create the service token at Access controls → Service credentials → Service Tokens tab → Add a service token, then paste them here.

3.3 Lock Down Admin SSH

The attacker also reached the admin box on :22. Bring SSH to the Linux server under Access for Infrastructure so only the IT team can connect, connections require the same device posture, and access uses short-lived certificates instead of static keys (which is what kills the "rotate every key after a breach" fire drill). Command logging should be on.

3.4 Bring In the Contractor (Clientless)

A contractor on a laptop you do not manage needs one internal app. You cannot install WARP and you cannot run a posture check, so identity-plus-agent is off the table - this is the fourth use case, clientless. Publish the app as a self-hosted (reverse-proxy) Access application named AcmeCorp-Contractor on contractor.<your-domain>, with an Allow policy for the contractor identity. Because it is reverse-proxied, the contractor reaches it in a browser and logs in with no client at all.

3.5 Reach the Private Host Without a Bastion

The principle is reach a server in the private space from the public space, identity-brokered, with no bastion host. Stand up a browser-rendered infrastructure app: a self-hosted Access application named AcmeCorp-Infra with browser rendering set to SSH for the private host, an Allow policy for the IT group (no Bypass, no Service Auth), and a tunnel ingress that maps the app hostname to localhost:22. The session runs entirely in the browser - no client, no exposed port.

curl.exe -s -o NUL -w "no-session %{http_code}`n" https://billing.<your-domain>/

curl.exe -s -o NUL -w "with-token %{http_code}`n" -H "CF-Access-Client-Id: <service-client-id>" -H "CF-Access-Client-Secret: <service-client-secret>" https://billing.<your-domain>/

curl.exe -s -o NUL -w "contractor %{http_code}`n" https://contractor.<your-domain>/

Phase 4 - Gateway

4.1 Block the C2 Domain

Threat intel identified the command-and-control domain the compromised laptop was beaconing to: malware-c2-test.example. Add a Gateway DNS policy named AcmeCorp-DNS-Block that blocks resolution of that specific domain — match on the Domain selector (value malware-c2-test.example), not a security category: this is a synthetic domain that threat-intel categories do not cover, so a category-based rule will never fire on it. Make sure the block page is enabled so a blocked user sees an explanation instead of a silent failure.

4.2 Segment the Admin Box

Lateral movement to the admin box on :22 should have been impossible for a non-IT device. Add a Gateway Network policy named AcmeCorp-Net-AdminLockdown that blocks TCP to the admin box on port 22 for everyone except the IT group, and order it so it is evaluated before any broad allow.

4.3 Inspect TLS (and What Not To)

The PII exfil in Phase 5 rode out over HTTPS, so the Gateway has to be able to see inside TLS. Turn on TLS decryption account-wide. Then add one Do-Not-Inspect rule named AcmeCorp-TLS-Bypass for a cert-pinned application that breaks under decryption (the number-one post-decryption support ticket). For this lab, use www.google.com as that pinned host: match on the host www.google.com with action Do Not Inspect. Leave every other site decrypted — in particular do not bypass www.example.com, which must stay decrypted so the check can confirm it presents the Cloudflare certificate.

4.4 Build the Deny-All Floor

In your Cloudflare account dashboard, open Zero Trust → Traffic controls → Firewall policies → HTTP and select Add a policy.

In Scope → And traffic matches, add a Host condition with operator in; click Copy on each block below, paste it into the Value field, and press Enter before adding the next host.

Set Then → Action to Allow; in Details → Policy name, paste the copied name below, leave Set policy as active on, and select Create policy.

AcmeCorp-HTTP-Allow

On the same HTTP tab, select Add a policy again; under Scope → And traffic matches, choose Host, operator matches regex, and paste the copied pattern below into Value to match any HTTP hostname not already allowed.

.*

Set the action to Block, paste the copied name below into Details → Policy name, leave the policy active, and select Create policy.

AcmeCorp-HTTP-DenyAll

Drag AcmeCorp-HTTP-DenyAll to the last row of the HTTP policy list, below AcmeCorp-HTTP-Allow and your other HTTP policies.

Open Traffic controls → Firewall policies → Network and select Add a policy.

For the private SSH exception, use And traffic matches with Destination IP is and Destination Port is; paste the first and second copied values below into their respective fields, then under And identity matches use User Group Names in and paste the third value (the IT group from your SAML identity provider, not an Access rule group).

Set the action to Allow, paste the copied name below into Details → Policy name, leave the policy active, and select Create policy.

AcmeCorp-Net-Allow-IT-SSH

On the Network tab, select Add a policy again and set And traffic matches → Destination IP → in; paste the copied range below into Value and leave identity and posture conditions empty so this rule catches all other connections to the lab's private range.

10.91.0.0/16

Set the action to Block, paste the copied name below into Details → Policy name, leave the policy active, and select Create policy.

AcmeCorp-Net-DenyAll

Drag AcmeCorp-Net-DenyAll to the last row of the Network list, below the non-IT SSH Block from 4.2 and the IT SSH Allow; leave the non-IT SSH Block above that Allow.

4.5 Isolate the Contractor's Browser

The clientless contractor app from 3.4 still lets data land on a device you do not control. Add a Gateway HTTP policy named AcmeCorp-Contractor-Isolate with the Isolate action for the contractor app, and turn on the Browser Isolation admin controls that disable clipboard (copy/paste), downloads, uploads, and printing. The app now runs in an isolated remote browser, so nothing leaves the isolated session onto the untrusted endpoint.

nslookup malware-c2-test.example

curl.exe -s -o NUL -w "admin-ssh %{http_code}`n" --connect-timeout 5 http://<ubuntu-ip>:22/

curl.exe --ssl-no-revoke -s -o NUL -w "allowlisted %{http_code}`n" https://www.example.com/

curl.exe --ssl-no-revoke -s -L --connect-timeout 5 --max-time 12 -o NUL -w "not-allowlisted %{http_code}`n" https://example.org/

AcmeCorp-HTTP-DenyAll

Phase 5 - DLP

5.1 Stop the PII Exfil

AcmeCorp customer IDs look like ACME-1234-5678. Create a DLP profile named AcmeCorp-PII with a custom detection entry that matches that pattern (regex ACME-\d{4}-\d{4}), then add a Gateway HTTP policy with action Block that references the profile and stops uploads carrying that data to personal cloud storage.

curl.exe --ssl-no-revoke -s -o NUL -w "dlp-upload %{http_code}`n" -X POST https://httpbin.org/post -d "customer=ACME-1234-5678"

Phase 6 - Seal

6.1 Seal the Breach Path & Validate

Ensure the billing intranet cannot be reached directly by IP; the only route to it must be the Cloudflare Tunnel behind your Access policy. If your direct request worked in Phase 0, it must now fail. If the managed pod already closed that route, confirm it stays closed while billing.<your-domain> enforces Access.

curl.exe -s -o NUL -w "direct   %{http_code}`n" --connect-timeout 5 http://<ubuntu-ip>:8000/
curl.exe -s -o NUL -w "cf-none  %{http_code}`n" https://billing.<your-domain>/

Phase 7 - Accountability

7.1 Stand Up Your Own Log Sink

In your Cloudflare account dashboard, open Compute → Workers & Pages and check the Account details card on the right for a Subdomain ending in .workers.dev.

Get the files on Ubuntu

In the lab portal, select Ubuntu origin and open its Bash terminal (the prompt looks like cloudflare@origin-server:~$).

Copy the next block into that terminal to download the log-sink files from this capstone site to ~/zt-capstone-logsink.

curl -fsSL https://zt-capstone.cloudflareacademy.com/logsink/download.sh -o /tmp/zt-capstone-logsink-download.sh && bash /tmp/zt-capstone-logsink-download.sh && cd "$HOME/zt-capstone-logsink" && ls deploy.sh worker/zt-logsink.js

In the Ubuntu terminal, copy this block to install Terraform if needed and print its version; it is safe to run again if you installed Terraform already.

cd "$HOME/zt-capstone-logsink" && ./install-terraform.sh

Deploy the log sink

Check that both export lines in the deploy block show your real values rather than orange angle-bracket placeholders.

Copy the whole block below into the Ubuntu origin Bash terminal; it moves into the downloaded folder, supplies the two values to Terraform, and runs deploy.sh.

cd "$HOME/zt-capstone-logsink" &&
export TF_VAR_cloudflare_account_id="<cf-account-id>" &&
export TF_VAR_cloudflare_api_token="<cf-api-token>" &&
./deploy.sh

Copy the Sink URL and Sink token from the Ubuntu terminal output into the matching fields below.

In the Ubuntu origin Bash terminal, copy this authenticated check after filling both sink fields. It verifies that the deployed Worker accepts your token and can read its database; the public /health route cannot check either one.

curl -fsS "<sink-url>/stats?token=<sink-token>"

Connect the first Logpush job: Gateway HTTP

In your Cloudflare account dashboard, open Observability → Export → Logpush and stay in the Account-scoped Logpush section (not the zone/domain section).

Click Create a Logpush job and choose HTTP destination.

In Enter destination details, paste the first line below into the required HTTP endpoint field (the same gateway_http URL printed by deploy.sh); this is a destination URL for the dashboard, not a terminal command.

<sink-url>/ingest?token=<sink-token>&dataset=gateway_http

Click Continue to validate the HTTP endpoint; the log-sink Worker answers Cloudflare's test request for you.

Under Select dataset, choose the Zero Trust Gateway HTTP dataset.

Under Configure logpush job, give the job a name, leave it enabled, and create it.

Connect the second Logpush job: Access requests

Return to Observability → Export → Logpush → Account-scoped Logpush, click Create a Logpush job, and choose HTTP destination again.

In Enter destination details, paste this second line into HTTP endpoint instead of the Gateway HTTP line.

<sink-url>/ingest?token=<sink-token>&dataset=access_requests

Click Continue to validate the endpoint, select the Zero Trust Access requests dataset, name the job, leave it enabled, and create it.

Pull and check your logs

On the enrolled Win11 client, open billing.<your-domain> in the browser and visit a website your Gateway allowlist permits so the two jobs have traffic to send.

Return to the Ubuntu origin Bash terminal and copy this block to pull the Gateway HTTP logs into a readable table.

cd "$HOME/zt-capstone-logsink" && ./pull-logs.sh "<sink-url>" "<sink-token>" gateway_http 50

You can also open the lightweight sink viewer in a browser to see what has landed.

Submit & Grade

When you have worked through the phases, switch to the lab portal's Win11 client tab and open Windows PowerShell on that desktop.

Copy the grading command into that Win11 PowerShell window:

irm https://zt-capstone.cloudflareacademy.com/capstone | iex

Log in with your course email and your capstone access code, paste your read-only account-scoped token, and give the runner the Sink URL and SINK_TOKEN from the Phase 7 deploy output when it prompts for them. It fetches sink rows on Win11, prints a per-item pass/fail list, and emails you the same rubric; all 16 items must pass. A failed item tells you why it is failing but not the fix. Correct it and re-run: there is no retry limit.

Deliverables Checklist

All 16 must pass. This is the exact list the grader scores, in phase order.

Troubleshooting

Architecture Recap

You took AcmeCorp from a flat, VPN-trusted network with a live breach path to a sealed, validated Cloudflare One posture. Here is what each layer defends.