This is my main Cloudflare Zero Trust engineering lab: a Terraform-managed environment that spans AWS, Azure and Google Cloud and gives me a repeatable place to test Access, Gateway, WARP routing, device posture and related integrations together.
Objective
The goal is to test complete access paths rather than isolated product features.
The environment lets me work through questions such as:
- how private resources in several clouds can use a common Zero Trust access layer;
- how WARP Connector routing compares with traditional VPN connectivity;
- how identity, device posture and application policy interact;
- where browser-rendered SSH, RDP and VNC can reduce direct management exposure;
- how external evaluators and custom denial Workers fit into Access;
- how to destroy and rebuild the environment safely.
Main architecture
Users and enrolled devices
↓
Cloudflare Zero Trust
Access / Gateway / WARP
posture / private routing
↓
AWS + Azure + Google Cloud
↓
Demo workloads and management servicesTerraform manages a large part of both the cloud-provider infrastructure and Cloudflare configuration.
Cloudflare resources
The Cloudflare module contains configuration for areas including:
- Access applications and policies;
- Gateway policies;
- device/WARP profiles;
- DNS records;
- rule groups;
- private network tunnels;
- short-lived certificate and SSH CA use cases;
- related Zero Trust tags and supporting resources.
Cloud-provider workloads
The project deploys representative resources into all three cloud providers so the same Cloudflare control plane can be tested against different network environments.
The individual virtual machines matter less than the ability to compare access patterns while the underlying cloud changes.
WARP routing
A dedicated module calculates routing data from the infrastructure definition instead of relying entirely on manually maintained client-route lists.
This keeps private-network policy closer to the networks Terraform actually created.
Access and posture
The environment includes multiple Access policy patterns plus device posture checks so I can test identity-only decisions against identity-plus-device decisions.
Supporting scripts can also update operating-system version posture rules when reference versions change.
Optional Worker integrations
The lab integrates with two separate Worker projects when enabled:
The first adds an external training-compliance decision to Access. The second improves the user/support experience when Access denies a request.
Terraform backend
The main project uses a separate backend repository:
https://github.com/azurepeter/cloudflare-zero-trust-demo-backend
That backend creates the persistent AWS storage/locking infrastructure used by the lab state.
Keeping backend infrastructure outside the disposable demo environment means I can destroy the lab without destroying the state platform that manages its lifecycle.
Bootstrap and manual boundaries
The repository documents values that must be supplied from Cloudflare or identity-provider setup rather than pretending every prerequisite is automatically discoverable.
That includes identifiers for some tunnels, identity-provider integrations, posture configuration and groups.
The important design choice is that those manual boundaries are explicit and repeatable.
Cleanup
The project includes cleanup tooling for artifacts that sit outside the normal Terraform destroy graph, such as temporary SSH known-host entries and Cloudflare device registrations used during testing.
A lab should be easy to remove as well as easy to create.
Typical Terraform workflow
terraform init -backend-config=backend.conf
terraform fmt -check
terraform validate
terraform plan
terraform applySecrets and provider credentials are supplied through environment variables or ignored configuration rather than committed to the repository.
Related article
See Building a Multi-Cloud Zero Trust Lab with Cloudflare and Terraform for the architecture decisions and lessons from using the environment as an integrated Zero Trust test platform.
