Bill Gernert
Networking & Edge

Cloudflare Tunnel / Access

The lab's public edge uses an outbound-only tunnel. Access protects administrative and private apps, while the portfolio and sanitized status routes remain public by design.

What it is and whyHow I use it inArchitectureLessons learned and gotchasImpactFurther reading

What it is & why I use it

Cloudflare Tunnel and Cloudflare Access are how the lab is reachable from the internet without punching holes in the firewall. A tunnel connector inside the network makes an outbound connection to Cloudflare; traffic to the public hostnames is delivered back down that connection to the internal ingress. There is no inbound application port for these published routes.

Cloudflare Access enforces SSO in front of protected apps. The portfolio and approved, sanitized status routes remain anonymous by design; other status-host routes fail closed. The tunnel keeps the origin from being directly exposed while the public surface stays explicit and narrow.

How I use it in the lab

  • Outbound-only tunnel. A connector dials out to the edge; the origin is not addressable from the internet, so there is nothing to port-scan or brute-force at the perimeter.
  • Ingress behind the tunnel. The tunnel hands traffic to the internal reverse proxy, which routes to each service - so adding an app is an ingress rule, not a firewall change.
  • SSO on protected apps. Access sits in front of administrative and private hostnames; interactive users authenticate through the identity provider before the app is reached.
  • TLS from the automated CA. Certificates for internal names are issued and renewed automatically by cert-manager via a DNS-01 challenge, so nothing depends on a person remembering to rotate a cert.
  • Service tokens for machines. Automation that must call an Access-protected app presents a non-interactive service token, so the SSO wall stays up without blocking legitimate machine-to-machine calls (see the gotcha).

Architecture

Cloudflare Tunnel / Access architecture: Protected app without an inbound port A request for a protected application reaches Cloudflare Access, passes the identity gate, crosses an outbound tunnel to internal ingress, and arrives without an inbound origin rule. ARCHITECTURE FLOW PROTECTED APP WITHOUT AN INBOUND PORT Internet request: A user opens the protected service INTERNET REQUEST A user opens the protected service Access SSO: Identity policy evaluates the request ACCESS SSO Identity policy evaluates the request Cloudflare edge: The public service terminates here CLOUDFLARE EDGE The public service terminates here Outbound tunnel: The origin opens the connection outward OUTBOUND TUNNEL The origin opens the connection outward Internal ingress: Route to the intended service INTERNAL INGRESS Route to the intended service Application: No inbound origin port is open APPLICATION No inbound origin port is open Cyan. Automated step or path. Amber. Operator or policy gate. Green. Recorded or healthy outcome. Rounded box. Actor or process. Arrow. Direction of work or data.
The protected-application path runs through Cloudflare Access and an outbound tunnel to internal ingress and the application. Hostnames, connector addresses, and certificate names are omitted.

Lessons learned & gotchas

Gotcha - SSO in front of an app blocks your automation too Access protects interactive users beautifully and machines not at all: a script hitting an SSO-fronted hostname gets an interactive login page, not the app, and fails in a way that looks like a broken credential. The wrong fix is to carve an exception into the policy - that quietly reopens the very door you closed. The right fix is an Access service token: a non-interactive credential the automation presents to satisfy Access without weakening it for anyone else. Keep the wall up; give machines a proper key, not a hole.
  • Outbound-only changes the threat model. With no inbound port, the classic "scan the perimeter and pound on the login" attack has nothing to aim at. It is worth the slightly less obvious mental model that traffic arrives "backwards" down a tunnel.
  • Automate certificate renewal or it will bite you. A cert someone has to remember to renew is an outage with a date on it. DNS-01 issuance via cert-manager makes renewal a non-event.
  • Identity at the edge is not a substitute for identity at the app. Access is a strong outer gate, but services still enforce their own authorization - defense in depth, not a single wall.

Impact

0
inbound application ports
SSO
on protected apps
Auto
TLS issuance / renewal

Cloudflare Tunnel and Access keep the origin unreachable while protected apps sit behind an identity gate and approved public routes stay intentionally anonymous. The service-token lesson is the one that generalizes: a security control that breaks legitimate automation will get weakened by whoever is under deadline - so the durable answer is to give machines a proper credential, never to poke a hole in the wall.

Further reading

Cloudflare Tunnel Access service tokens