Cloudflare SASE: Seven Protections and Where Tunnel Fits

SASE (Secure Access Service Edge) is the idea, coined by Gartner in 2019, that networking and network security should stop being separate boxes in a data center and instead converge into a single cloud-delivered service. Instead of backhauling every remote worker through a VPN concentrator so a stack of appliances can inspect their traffic, users and offices connect to the nearest edge location of a global network, and every security policy is enforced right there, close to the user, for all traffic at once.

Cloudflare's implementation of this model is Cloudflare One. It runs on the same global anycast network as the rest of Cloudflare, which means every data center runs every service: a request is authenticated, filtered, inspected, and logged in a single pass at whichever location the user happens to hit.

What Are the Two Halves of SASE?

Every SASE platform is really two products fused together. One half is network-as-a-service: the plumbing that gets packets from users, devices, offices, and servers onto the provider's network. In Cloudflare's case that is the WARP device client, Cloudflare Tunnel for connecting servers and private networks without opening inbound ports, and Magic WAN and Magic Transit for whole-site and whole-network connectivity.

The other half is the security stack, often called SSE (Security Service Edge), that sits on top of that plumbing and decides what traffic is allowed to do. This is where the actual protections live, and it is the half people mean when they ask what SASE protects against.

What Are the Seven Protection Layers in Cloudflare SASE?

Cloudflare One ships seven distinct protection services. Each one answers a different question about your traffic, and they compose: the same request can pass through several of them in one trip through the edge.

Alongside these seven, Cloudflare One also ships Digital Experience Monitoring (DEM), which observes connectivity and performance rather than blocking anything, so I count it as observability rather than a protection layer.

How Does a Cloudflare Tunnel Setup Fit Into ZTNA?

The guide that makes up the rest of this post publishes internally self-hosted applications through Cloudflare Tunnel and locks them behind identity, device posture, and access policies. It is worth being precise about the category: Cloudflare Tunnel itself is not a protection, it is plumbing from the network-as-a-service half. It creates an outbound-only connection from your server to Cloudflare's edge, so the app needs no open inbound ports and no public IP exposure.

The protection wrapped around that tunnel is ZTNA. Every request to the app's hostname is intercepted by Cloudflare Access, which verifies who the user is against the identity provider, checks that their device is enrolled and passing posture checks, and only then lets the request through to the tunnel. No user or device is trusted by default, access is evaluated per application and per request, and the private network is never exposed. That is the definition of Zero Trust Network Access.

The Integration Guide

This guide covers the end-to-end setup for protecting internally self-hosted applications behind a Cloudflare tunnel, enforced by Zero Trust access policies. It covers identity provider integration, tunnel configuration, device posture, access policies, and client deployment via Docker.

1 · Identity Provider Setup

Path: Integrations > Identity Providers

Adding Google as an Identity Provider

1. 01
   Add the provider

   Click Add identity provider and select Google.

2. 02
   Retrieve credentials

   Retrieve the Client ID and Client Secret from Google Cloud Console. The OAuth 2.0 app type must be Web Application.

3. 03
   Enable PKCE

   Enable Proof Key for Code Exchange (PKCE): ON.

4. 04
   Save and verify

   Click Save, then use the Test button to verify the connection.

2 · Networks: Tunnel Configuration

Path: Networks > Connectors

Creating the tunnel

1. 01
   Choose the connector type

   Select tunnel type: Cloudflared.

2. 02
   Name it

   Name the tunnel and click Next.

3. 03
   Copy the token

   Copy the generated cloudflared tunnel token. This is needed for deployment.

4. 04
   Continue

   Click Next to proceed to the application route setup.

Configuring the published application route

This step maps a subdomain to the internal service that should be tunneled.

Click Save. This can be updated later if needed.

3 · Reusable Components: Posture Checks

Path: Reusable Components > Posture Checks

Create two posture checks, one for WARP and one for Gateway:

1. 1Click Add a check.
2. 2Pick WARP from the list. The name is auto-filled. Save.
3. 3Click Add a check again.
4. 4Select Gateway. The name is auto-filled. Save.

4 · Access Controls: Policies

Path: Access Controls > Policies

Three policies need to be created. Each is referenced by name in later steps.

Policy 1: Team Email Check

Leave all other settings as default and save.

Policy 2: PostureCheck

Click +Add require to add the Gateway rule. Leave everything else default and save.

Policy 3: Webhook Public Bypass

Leave everything else default and save.

5 · Access Controls: Applications

Path: Access Controls > Applications

Two applications need to be created: one for the protected app, and one for public webhook paths.

Application 1: Protected App

Destinations: under Public Hostnames, add the same subdomain and domain configured in the tunnel step. Leave the path empty to protect all routes.

• Allow access through browser-based RDP, SSH, or VNC sessions: OFF

Access Policies: add existing policy and select PostureCheck (Step 4, Policy 2).

Set the App name and Session duration to 6 hours. Save.

Application 2: Public Webhook Paths

Before the how, the why: not every route in an app can sit behind interactive authentication. Webhook endpoints are called machine-to-machine by outside services (a payment provider, a Git host, an automation trigger) that cannot complete a browser login against your identity provider, so an auth challenge would silently break the integration. This second application exists to carve exactly those public routes out of Zero Trust enforcement while every other path on the same hostname stays protected. Keep the carve-out as narrow as possible and lean on the app's own safeguards for those routes, such as webhook signature verification or secret tokens in the URL.

Destinations: under Public Hostnames, use the same subdomain and domain. In the Path field, enter the webhook path that must remain publicly accessible without third-party authentication. For example, n8n exposes two paths: /webhook and /webhook-test.

Access Policies: add existing policy and select Webhook Public Bypass (Step 4, Policy 3).

• Accept all available identity providers: ON (likely inconsequential for a Bypass policy)

Set a name and Session duration to 1 month. Save.

6 · Access Controls: App Launcher

Path: Access Controls > Access Settings > Manage your App Launcher

Verify the following configuration is in place:

7 · Team & Resources: Device Profile

Path: Team & Resources > Devices > Device Profiles

Creating the Onboarding Profile

Profile Settings

Split Tunnels

Select Exclude IPs and domains, then click Manage. Find the address 100.64.0.0/10 and delete it.

Save the profile.

8 · Devices: Management

Path: Devices > Management

Device Enrollment Permissions

1. 01
   Open the policies

   Go to Device enrollment permissions > Manage > Policies.

2. 02
   Attach the email policy

   Select existing policies and choose Team Email Check (Step 4, Policy 1). Save.

3. 03
   Set the login method

   Switch to the Login methods tab, select Google, and save.

Global Device Client Settings

Global Disconnection Settings

Mesh Connectivity

9 · Secure Web Gateway: Traffic Settings

Path: Secure Web Gateway > Traffic Policies > Traffic Settings

Proxy and Inspection

Policy Settings

All of the following can be enabled as needed, leave OFF by default:

Traffic Logging

Set Log traffic activity to Capture All for all three categories.

10 · Cloudflared Client Deployment (Docker)

The cloudflared client can be deployed in multiple ways. This guide covers the Docker method, specifically for self-managed systems like Coolify or AWS ECS (Elastic Container Service), where you control the Docker networks and containers yourself.

None of this is specific to Docker or Coolify either. Any internal service can be protected this way as long as a cloudflared client can be deployed in front of it, whether that is a bare metal VM, a Kubernetes cluster, or another container runtime. The Docker network example is what this guide walks through because it is the closest to a real production setup.

To keep these manageable, deploy all cloudflared instances in a single dedicated Coolify project and follow a consistent naming convention: [ServerName_ServerModel].

Deployment Steps

1. 01
   Create the client

   Create and assign the client to its server using the Coolify Cloudflared template (uses the latest image).

2. 02
   Set the tunnel token

   Go to the Environment Variables section and put the token we copied in Step 2 as the value of CLOUDFLARE_TUNNEL_TOKEN and save.

3. 03
   Remove host networking

   Edit the generated Docker Compose file: remove the network_mode: host entry from the cloudflared service.

Add the following inside the cloudflared service block:

networks:
  - coolify

Outside of the services block, add the external network declaration:

networks:
  coolify:
    external: true

Apply the same external network setup to the target app's Compose file (e.g. the n8n instance). This injects the cloudflared client into the shared Docker network, allowing it to resolve service names.

What to Expect Once Fully Configured

• The service is protected behind the Cloudflare tunnel. Only enrolled users who have authenticated via the identity provider can access the app's subdomain. Unauthenticated requests are dropped.
• Anyone without the Cloudflare One Client can still reach the team's App Launcher page, but attempting to use the identity provider will fail. The client being off triggers an error.
• Anyone with the client installed and running but not enrolled will fail the IdP check, as their email is not on the allow-list.

Closing Notes

Of the seven protection layers Cloudflare SASE offers, this setup exercises one fully (ZTNA) and one partially (SWG, through the WARP client and Gateway proxy settings in Section 9). That is a deliberate starting point rather than a limitation: once devices are enrolled and traffic flows through the edge, turning on TLS inspection, DLP, or malware scanning is a dashboard toggle away, not a new architecture. Start with ZTNA for the apps that must never be public, and grow into the rest of the stack as the need appears.