/deploying-cloudflare-access-for-zero-trust

name: deploying-cloudflare-access-for-zero-trust
description: 'Deploying Cloudflare Access with Cloudflare Tunnel to provide zero trust access to self-hosted and private applications,
  configuring identity-aware access policies, device posture checks, and WARP client enrollment for VPN replacement.

  '
domain: cybersecurity
subdomain: zero-trust-architecture
tags:
- cloudflare
- cloudflare-access
- zero-trust
- cloudflare-tunnel
- warp
- ztna
- cloudflare-one
version: '1.0'
author: mahipal
license: Apache-2.0
atlas_techniques:
- AML.T0051
- AML.T0054
- AML.T0056
nist_ai_rmf:
- MEASURE-2.7
- MEASURE-2.5
- GOVERN-6.1
- MAP-5.1
nist_csf:
- PR.AA-01
- PR.AA-05
- PR.IR-01
- GV.PO-01

Deploying Cloudflare Access for Zero Trust

When to Use

• When replacing VPN infrastructure with identity-aware application access using Cloudflare One
• When exposing self-hosted internal applications through Cloudflare Tunnel without opening inbound ports
• When implementing ZTNA for a distributed workforce accessing web applications, SSH, and RDP services
• When needing a cost-effective zero trust solution with integrated DLP, CASB, and SWG capabilities
• When securing contractor and third-party access to specific applications without full network access

**Do not use** for applications requiring persistent UDP connections not supported by Cloudflare Tunnel, for environments requiring air-gapped or fully on-premises access control, or when regulatory requirements prohibit routing traffic through third-party cloud infrastructure.

Prerequisites

• Cloudflare account with Zero Trust subscription (Free for up to 50 users, paid plans for larger teams)
• Domain name managed by Cloudflare DNS (or ability to add CNAME records)
• Linux, Windows, or macOS server to run `cloudflared` tunnel daemon
• Identity provider: Okta, Microsoft Entra ID, Google Workspace, GitHub, or any SAML/OIDC provider
• Cloudflare WARP client for device-level enrollment (optional but recommended)

Workflow

Step 1: Create a Cloudflare Tunnel to Internal Applications

Install `cloudflared` and create a persistent tunnel to expose internal services.

# Install cloudflared on Ubuntu/Debian
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb \
  -o cloudflared.deb
sudo dpkg -i cloudflared.deb

# Authenticate cloudflared with your Cloudflare account
cloudflared tunnel login

# Create a named tunnel
cloudflared tunnel create internal-apps
# Output: Created tunnel internal-apps with id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# Configure tunnel routes to internal applications
cat > ~/.cloudflared/config.yml << 'EOF'
tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
credentials-file: /home/admin/.cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

ingress:
  - hostname: wiki.company.com
    service: http://localhost:8080
  - hostname: git.company.com
    service: http://10.1.1.50:3000
  - hostname: grafana.company.com
    service: http://10.1.1.60:3000
  - hostname: ssh.company.com
    service: ssh://localhost:22
  - hostname: rdp.company.com
    service: rdp://10.1.1.100:3389
  # Catch-all rule (required)
  - service: http_status:404
EOF

# Route DNS to the tunnel
cloudflared tunnel route dns internal-apps wiki.company.com
cloudflared tunnel route dns internal-apps git.company.com
cloudflared tunnel route dns internal-apps grafana.company.com

# Run tunnel as a systemd service
sudo cloudflared service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared

# Verify tunnel status
cloudflared tunnel info internal-apps

Step 2: Configure Identity Provider Integration

Set up authentication with your organization's identity provider.

# Using Cloudflare API to configure Okta as IdP
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/access/identity_providers" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "Corporate Okta",
    "type": "okta",
    "config": {
      "client_id": "OKTA_CLIENT_ID",
      "client_secret": "OKTA_CLIENT_SECRET",
      "okta_account": "company.okta.com",
      "api_token": "OKTA_API_TOKEN",
      "claims": ["email", "groups", "name"],
      "email_claim_name": "email"
    }
  }'

# Configure Microsoft Entra ID as additional IdP
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/access/identity_providers" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "Microsoft Entra ID",
    "type": "azureAD",
    "config": {
      "client_id": "AZURE_APP_CLIENT_ID",
      "client_secret": "AZURE_APP_CLIENT_SECRET",
      "directory_id": "AZURE_TENANT_ID",
      "support_groups": true,
      "claims": ["email", "groups", "name"]
    }
  }'

Step 3: Create Access Applications and Policies

Define Access applications with identity-aware policies for each internal service.

# Create Access application for internal wiki
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/access/apps" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "Internal Wiki",
    "domain": "wiki.company.com",
    "type": "self_hosted",
    "session_duration": "8h",
    "auto_redirect_to_identity": true,
    "http_only_cookie_attribute": true,
    "same_site_cookie_attribute": "lax",
    "logo_url": "https://company.com/wiki-logo.png",
    "allowed_idps": ["OKTA_IDP_ID", "AZURE_IDP_ID"]
  }'

# Create Allow policy for the wiki application
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/access/apps/{app_id}/policies" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "Allow Engineering Team",
    "decision": "allow",
    "precedence": 1,
    "include": [
      {"group": {"id": "ENGINEERING_GROUP_ID"}},