Replacing SSH Bastions With Cloudflare Tunnel and Access
Cloudflare's internal engineering teams historically accessed PostgreSQL clusters — which power services like Stream, Images, and the Cloudflare Dashboard — through SSH bastion hosts. Those clusters run on dedicated hardware inside Cloudflare data centers and are never exposed directly to the public internet. Employees needing database access for staging environments, incident response, or production support required a limited SSH account on a bastion host just to query databases inside the data center.
That workflow came with real costs. Provisioning an SSH account meant opening a pull request against the central Infrastructure-as-Code repository — a cumbersome process for engineers and an even heavier lift for non-engineers who either had to learn Git or ask someone else to do the work for them. Security and Site Reliability Engineering teams also had reservations about granting shell access to internal hosts. The accounts were restricted in privilege, but any shell access carries inherent risk and demands significant trust that the entire stack is secure.
A Zero Trust Approach to Database Connectivity
The solution Cloudflare adopted is built from its own products: Cloudflare Tunnel and Cloudflare Access. A Cloudflare Tunnel was deployed on a pod running inside an internal Kubernetes cluster with connectivity to the database clusters, establishing an outbound connection from the origin to the Cloudflare global network. This approach simplified orchestration — no more managing Access Control List (ACL) changes for the pod just so cloudflared could reach it.
Identity-driven Zero Trust policies were then configured in Cloudflare Access to control which employees could reach database endpoints. Access handled authentication for every request arriving over the Tunnel and enforced the predefined policies, ensuring only authorized Cloudflare employees could establish connections. The team also created separate Tunnels for staging and production databases, enabling granular restrictions on production access without slowing down work on staging environments. This also cleanly separated internal network policies.
Connecting From a Laptop
On the client side, users only need to install cloudflared on their machine. Running cloudflared access opens a long-lived TCP connection from the local laptop to the target database cluster. Each request is routed to Cloudflare first, where Access evaluates it against the Zero Trust policies and prompts the user for authentication. Once the user passes policy checks, the connection flows through Cloudflare Tunnel to the internal database. From there, a user can point any database client at a local port and run queries as though the database were running locally.
A break glass procedure remains in place: SSH-based jump-hosts are still maintained for a small set of senior staff members, so that if the Tunnel infrastructure itself fails, there is a fallback path to restore connectivity.
Operational Takeaways
Adopting its own products let Cloudflare tighten its security posture while streamlining the experience for internal users. The engineering teams became early customers of Tunnel and Access, providing feedback and feature requests, and catching regressions in beta builds before those changes reached external customers.
By forwarding arbitrary TCP connections through Access and Tunnel, users no longer need to manage complex SSH commands and configurations — and the Security and SRE teams gain the assurance that every connection into the data centers is authenticated, authorized, and logged by Cloudflare Access. Cloudflare Tunnel is free for any user and use case; teams can sign up for a Cloudflare Zero Trust account and create a Tunnel directly from the Zero Trust dashboard.
