Download and install cloudflared

Zero trust network architecture has become the standard for securing remote team access. Unlike traditional VPNs that create a perimeter around your network, zero trust verifies every request regardless of where it originates. Cloudflare Access provides a straightforward path to implement this security model without the complexity of traditional solutions.

This guide walks through setting up Cloudflare Access to protect your internal applications and resources for distributed teams.

Why Zero Trust Matters for Remote Teams

Traditional network security assumes everything inside your network is trustworthy. This model breaks down when your team works from coffee shops, home offices, and hotels across different time zones. A single compromised credentials can give attackers access to everything.

Zero trust eliminates this assumption. Every access request gets verified: Who is requesting access? What resource are they trying to reach? Has this user been granted permission? Cloudflare Access implements these checks without requiring clients to install software or route all traffic through a VPN tunnel.

The benefits extend beyond security. Your team gets fast access to internal tools from any location, and you eliminate the latency and complexity of traditional VPN infrastructure.

Prerequisites

Before starting, gather the following:

A Cloudflare account with Access available (included in Cloudflare Zero Trust plans)
Admin access to your identity provider (Google Workspace, Okta, Azure AD, or others)
Domain configured with Cloudflare DNS
Internal applications or resources you want to protect

Step 1: Configure Your Identity Provider

Cloudflare Access integrates with your existing identity provider to authenticate users. Setting this up takes a few minutes but provides the foundation for your zero trust implementation.

First, navigate to the Cloudflare dashboard and select “Access” from the sidebar. Go to “Authentication” and add your identity provider. The most common choice is Google Workspace:

Provider: Google
Auth Domain: yourcompany-admin.google.com
Client ID: your-client-id-from-google-cloud-console
Client Secret: your-client-secret

For Azure AD or Okta, select the appropriate provider type and enter the details from your IdP configuration. Cloudflare supports SAML and OAuth protocols, so most major identity providers work.

After connecting your IdP, create an authentication policy that requires users to authenticate before accessing any protected resource. This ensures every request gets validated against your identity provider.

Step 2: Set Up Application Tunnels

Cloudflare Access uses application tunnels to expose internal services without exposing them to the public internet. Instead of opening ports in your firewall, your services connect to Cloudflare through a lightweight daemon.

Install the cloudflared tunnel agent on your internal server or container:

# Download and install cloudflared
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o /usr/local/bin/cloudflared
chmod +x /usr/local/bin/cloudflared

# Authenticate with Cloudflare
cloudflared tunnel login

# Create a tunnel
cloudflared tunnel create remote-access-tunnel

The login command opens your browser to authenticate with Cloudflare. The tunnel creation command generates credentials your service will use to connect.

Next, configure which services the tunnel exposes:

# tunnel.yaml
tunnel: your-tunnel-uuid
credentials-file: /root/.cloudflared/your-tunnel-uuid.json

ingress:
  - hostname: internal.yourcompany.com
    service: http://localhost:8080
  - hostname: database.yourcompany.com
    service: tcp://localhost:5432
  - service: http_status:404

This configuration routes requests to internal.yourcompany.com to your local service on port 8080, while database traffic goes to PostgreSQL on port 5432. The final catch-all rule returns 404 for unmatched requests.

Start the tunnel:

cloudflared tunnel --config tunnel.yaml run remote-access-tunnel

Your internal services are now accessible through Cloudflare without being exposed to the public internet.

Step 3: Create Access Policies

Access policies define who can reach your protected resources. Cloudflare Access provides fine-grained control over these policies.

Create a policy from the “Applications” section:

Application name: Internal Dashboard
Session duration: 24 hours
Domain: dashboard.yourcompany.com

Policy rules:
  - Rule name: Engineering Team
    Include:
      - Group: Engineering (from your IdP)
    Require:
      - Approved Email Domain: yourcompany.com
    Exclude:
      - External Contractors

  - Rule name: Emergency Access
    Include:
      - Email: security@yourcompany.com
    Action: Allow

This policy grants engineering team members access while requiring company email addresses and excluding contractors. A separate rule ensures security personnel can always reach critical systems.

Cloudflare evaluates policies top-down, so order matters. Place more specific rules before general ones.

Step 4: Configure Browser-Based Access

For browser-based access to internal tools, Cloudflare Access provides a zero-client solution. Users navigate to your internal URL and get redirected to authenticate with your IdP.

This works for web applications, admin panels, and development tools. After authentication, Cloudflare proxies the request to your internal service. Users never see your internal IP addresses or network topology.

To enable this for a web application:

Add a new application in Access > Applications
Select “Self-hosted”
Enter your internal domain (e.g., git.internal.yourcompany.com)
Configure the policy rules
Point to your tunnel service

Users now access git.internal.yourcompany.com, authenticate through your company login, and reach your internal Git server without any VPN software.

Step 5: Set Up SSH and Database Access

Remote developers often need SSH access to servers or direct database connections. Cloudflare Access supports these use cases through its zero trust tunneling.

For SSH access, configure cloudflared on the client side:

# Install cloudflared on developer machine
brew install cloudflared  # macOS
# or
sudo apt install cloudflared  # Linux

# Add SSH configuration
# Add to ~/.ssh/config
Host jump-server
    HostName jump.yourcompany.com
    ProxyCommand cloudflared access ssh --hostname %h
    User %u

Developers then SSH through Cloudflare Access:

ssh user@production-server

The proxy command intercepts the connection, authenticates the user through your IdP, and establishes the tunnel. Database connections work similarly using the TCP proxy mode.

Step 6: Monitor and Audit Access

Zero trust requires visibility into who accesses what and when. Cloudflare Access provides logging and analytics out of the box.

Access the logs from the dashboard:

# Query access logs via API
curl -H "Authorization: Bearer your-api-token" \
  "https://api.cloudflare.com/client/v4/accounts/your-account-id/access_logs"

Key metrics to monitor:

Failed authentication attempts (indicates compromised credentials or misconfiguration)
Access from unusual locations (potential security threat)
Peak access times (helps with capacity planning)
Policy violation attempts

Set up alerts for suspicious activity through Cloudflare’s integration with your SIEM or notification tools.

Step 7: Implement Device Posture Checks

For enhanced security, verify that devices meet your security requirements before granting access. Cloudflare Access supports device posture checks:

Device posture rules:
  - Require: MDM enrolled (Jamf, Intune, or Kandji)
  - Require: Disk encryption enabled
  - Require: Operating system up to date (within 30 days)

These checks ensure remote devices meet your security standards before accessing sensitive resources. Employees working from personal devices can be restricted to less sensitive applications.

Practical Tips for Implementation

Start with Non-Critical Applications

Begin by protecting less sensitive tools like internal dashboards or documentation sites. This lets your team adapt to the authentication flow while you refine policies.

Gradually Decommission VPN

Once Cloudflare Access handles several applications, evaluate reducing VPN access. Many teams find they can eliminate VPN entirely for most use cases.

Document Access Patterns

Create internal documentation explaining how team members access different resources. Include troubleshooting steps for common authentication issues.

Plan for Emergencies

Always maintain a fallback access method for critical situations. Configure break-glass accounts with multi-factor authentication that your security team can use if Identity Provider experiences outages.

Common Pitfalls to Avoid

Overly restrictive policies. If users cannot access tools they need, they’ll find workarounds. Start permissive and tighten based on actual requirements.

Single point of failure. Ensure your identity provider has redundancy or maintain backup authentication methods.

Ignoring logging. Access logs reveal both security incidents and legitimate access patterns. Review them regularly.

Skipping user communication. Announce changes ahead of time and provide clear instructions. Surprise authentication prompts create friction and resistance.

Built by theluckystrike — More at zovo.one