Cloudflare Tunnel / Access - Skills

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 port open on the edge at all.

In front of the apps, Cloudflare Access enforces SSO: every published service requires an authenticated, authorized identity before a request ever reaches it. The two together give me a public presence with a genuinely small attack surface - the origin is never directly exposed, and nothing is anonymous.

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 every app. Access sits in front of each public hostname; human 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 human 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

Diagram coming Internet -> Cloudflare edge (Access SSO) -> outbound tunnel -> internal ingress -> app, with no inbound port on the origin. Scrubbed of hostnames, connector addresses, and cert names.

In action

Screenshot coming The Access login gate in front of a published app, and a healthy tunnel with no inbound firewall rule behind it. Captured per the publishing checklist - hostnames and addresses redacted.

Lessons learned & gotchas

Gotcha - SSO in front of an app blocks your automation too Access protects humans 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 ports open

SSO

on every public app

Auto

TLS issuance / renewal

Cloudflare Tunnel and Access let the lab have a real public presence while keeping the origin unreachable and every app behind an identity gate. 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.

Code & further reading

Tunnel / ingress config (link coming) Cloudflare Tunnel Access service tokens

Published config is scrubbed of hostnames, connector addresses, cert names, and any token material before it goes public.