Complete Setup Guide

Step 1: Install cloudflared on Master Node

SSH to the master node and install cloudflared:

ssh root@192.0.2.10
 
# Install cloudflared
apt-get update
apt-get install cloudflared -y
 
# Verify installation
cloudflared --version

My output:

cloudflared version 2026.5.0 (built 2026-05-15-1423 UTC)

Step 2: Create Tunnel via Dashboard

I chose the dashboard method (instead of CLI) because it’s easier for token-based authentication.

• Go to https://one.dash.cloudflare.com
• Navigate to: Networks → Tunnels
• Click Create a tunnel
• Choose: Cloudflared
• Name it: example-cluster
• Click Save tunnel

Result: Tunnel created with ID aaaabbbb-cccc-dddd-eeee-ffff00001111

Step 3: Install Tunnel on Server

The dashboard shows installation command. Copy the token and run:

# This creates systemd service and starts tunnel
cloudflared service install EXAMPLE_TOKEN_BASE64_ENCODED_STRING_REPLACE_WITH_YOUR_TUNNEL_TOKEN

This command:

• Creates /etc/systemd/system/cloudflared.service
• Creates /root/.cloudflared/ directory with credentials
• Starts cloudflared service
• Enables it to start on boot

Step 4: Create Configuration File

Create /etc/cloudflared/config.yml with all domain mappings:

mkdir -p /etc/cloudflared
nano /etc/cloudflared/config.yml

My configuration:

tunnel: example-cluster
credentials-file: /root/.cloudflared/aaaabbbb-cccc-dddd-eeee-ffff00001111.json
 
ingress:
  # Public services
  - hostname: example.com
    service: http://192.0.2.10:80
    originRequest:
      noTLSVerify: true
      connectTimeout: 30s
      httpHostHeader: example.com
 
  - hostname: app.example.com
    service: http://192.0.2.10:80
    originRequest:
      noTLSVerify: true
      connectTimeout: 30s
      httpHostHeader: app.example.com
 
  # Private services (will add Access later)
  - hostname: internal1.example.com
    service: http://192.0.2.10:80
    originRequest:
      noTLSVerify: true
      connectTimeout: 30s
      httpHostHeader: internal1.example.com
 
  - hostname: internal2.example.com
    service: http://192.0.2.10:80
    originRequest:
      noTLSVerify: true
      connectTimeout: 30s
      httpHostHeader: internal2.example.com
 
  - hostname: internal3.example.com
    service: http://192.0.2.10:80
    originRequest:
      noTLSVerify: true
      connectTimeout: 30s
      httpHostHeader: internal3.example.com
 
  # Catch-all
  - service: http_status:404
 
loglevel: info
logfile: /var/log/cloudflared.log
metrics: 0.0.0.0:2000

Why these settings:

• service: http://192.0.2.10:80 - nginx-ingress LoadBalancer external IP
• noTLSVerify: true - nginx-ingress uses self-signed certs
• httpHostHeader - nginx-ingress needs this to route to correct Ingress
• metrics: 0.0.0.0:2000 - Exposes Prometheus metrics for monitoring

Step 5: Restart cloudflared

Apply the configuration:

systemctl restart cloudflared
systemctl status cloudflared

Expected output:

● cloudflared.service - Cloudflare Tunnel
   Loaded: loaded (/etc/systemd/system/cloudflared.service; enabled)
   Active: active (running) since Fri 2026-05-23 08:15:32 UTC; 1min ago

Step 6: Verify Tunnel Connections

Check that tunnel has 4 HA connections:

curl http://localhost:2000/metrics | grep cloudflared_tunnel_ha_connections

My output:

cloudflared_tunnel_ha_connections 4

✅ 4 connections active to EU-Central data centers

Step 1: Update DNS Records

For each domain, I needed to change from A records to CNAME records pointing to the tunnel.

In Cloudflare Dashboard:

• Go to DNS → Records

• Delete existing A records for:

  • example.com
  • app.example.com
  • internal1.example.com
  • internal2.example.com
  • internal3.example.com

• Create CNAME records:

Step 2: Verify DNS Propagation

# Check DNS resolution
dig +short example.com @1.1.1.1
dig +short internal1.example.com @1.1.1.1

Expected: Cloudflare IPs (like 188.114.96.3, 188.114.97.3) NOT: Your server IP (192.0.2.10)

Step 3: Test Public Services

curl -I https://example.com
curl -I https://app.example.com

Look for:

HTTP/2 200
server: cloudflare
cf-ray: a00a00c5fce316f0-FRA

✅ Traffic is routing through Cloudflare!

Step 1: Create Access Application (ArgoCD)

• Go to Access → Applications
• Click Add an application
• Choose Self-hosted

Configuration:

• Application name: argocd
• Session Duration: 24 hours
• Application domain: internal1.example.com

Step 2: Create Access Policy

Policy name: Admin Access

Include rule:

• Selector: Emails
• Value: your@email.com (your email)

Authentication method:

• ☑ One-time PIN

Click Add application

Step 3: Repeat for Harbor and Grafana

Create applications for:

• harbor → internal2.example.com
• monitoring → internal3.example.com

Same policy: Email OTP for admin email.

Step 4: Test Access Authentication

Open https://internal1.example.com in a browser:

• You should see Cloudflare Access login page
• Enter your email
• Receive OTP code
• Enter code
• Access granted for 24 hours

✅ Private services now require authentication!

Step 5: Verify Access Logs

Go to Access → Logs → Access requests

You should see:

• Access events logged
• Email addresses
• Timestamps
• Allow/Deny decisions

Step 1: Install WARP Client

On your laptop/desktop:

• macOS: Download from https://1.1.1.1/ or brew install --cask cloudflare-warp
• Windows: Download from https://1.1.1.1/
• Linux: curl https://pkg.cloudflareclient.com/install | sudo bash

Step 2: Enroll WARP with Your Organization

• Open WARP client
• Click Settings → Preferences → Account
• Click Login to Cloudflare Zero Trust
• Enter your organization name: goalixa-zero-trust (or your org name)
• Authenticate with your email

WARP is now enrolled with your Zero Trust organization.

Step 3: Configure Split Tunnel

In the Cloudflare Dashboard:

• Go to Settings → WARP Client
• Click Device settings → Default
• Scroll to Split Tunnels
• Change mode to: Include IPs and domains
• Add your cluster IPs:

192.0.2.10/32    # Master node
192.0.2.11/32     # Worker1
192.0.2.12/32    # Worker2
192.0.2.13/32  # Worker3

What this does:

• Only cluster IPs route through WARP
• All other traffic (google.com, etc.) goes direct
• Minimizes WARP overhead for non-cluster traffic

Step 4: Enable Gateway

• Go to Gateway → Firewall Policies → Network
• Ensure Gateway is enabled
• Go to Settings → Network → Proxy
• Enable: ☑ Proxy
• Enable: ☑ Protocol Detection
• Protocols: ☑ TCP ☑ UDP ☑ ICMP

Step 5: Create Gateway Firewall Policies

Create two policies for cluster access:

Policy 1: Allow kubectl

• Name: Allow kubectl to Kubernetes Cluster
• Traffic:
  • Destination IP: 192.0.2.10
  • Destination Port: 6443
  • Protocol: TCP
• Action: Allow
• Logging: Enabled

Policy 2: Allow SSH

• Name: Allow SSH to Kubernetes Cluster
• Traffic:
  • Destination IPs: 192.0.2.10, 192.0.2.11, 192.0.2.12, 192.0.2.13
  • Destination Port: 22
  • Protocol: TCP
• Action: Allow
• Logging: Enabled

Step 6: Test kubectl Access

On your laptop with WARP connected:

# Connect WARP
warp-cli connect
 
# Wait for connection
warp-cli status
 
# Test kubectl
kubectl get pods -n default

It should work!

Disconnect WARP and try again:

warp-cli disconnect
kubectl get pods -n default

For kubectl (port 6443), it should still work because we haven’t closed the port yet.

Step 7: Verify Gateway Logs

Go to Logs → Gateway → Network

You should see:

• Traffic to 192.0.2.10:6443 (kubectl)
• Traffic to cluster IPs:22 (SSH)
• Action: Allow
• Your device identity

✅ WARP is routing cluster traffic through Gateway!