What Cloudflare Access is and why an admin panel needs it
Cloudflare Access places an identity check in front of the origin server: a user opens the panel address, sees a Cloudflare login form, and gets access only after confirming through email, a Google account, or corporate SSO. The request reaches the origin already carrying a "let in or not" decision.
For admin panels on a VDS, this closes a common hole: phpMyAdmin, a control panel, or a Git hook sitting on a public port gets found by scanners within the first day. Access removes the panel from the public zone, leaving identity checking in front of Cloudflare instead of on the server itself.
How Access differs from a VPN and a plain firewall
The difference lies in where the check happens and what is visible from outside before login.
| Criterion | VPN | Cloudflare Access |
|---|---|---|
| What is visible outside | An open VPN port on the server | A regular HTTPS domain with no extra ports |
| Client | A separate app and profile | A browser, no client install needed |
| Rule granularity | Access to the whole subnet at once | A separate policy per application |
How to connect an application in the Zero Trust dashboard
An application is created in the Zero Trust Dashboard under Access → Applications. There you specify the admin subdomain, for example admin.example.com, and the path to the origin server.
cloudflared tunnel login
cloudflared tunnel create admin-panel
cloudflared tunnel route dns admin-panel admin.example.comIf the server has no public IP address, it's worth setting up the application through Cloudflare Tunnel — then the admin port is never opened to the outside at all.
Access policies: who gets in and under what conditions
An Access policy is a set of conditions checked before a session is issued. Conditions can be combined in a single rule:
- email or mail domain — access limited to company employees
- membership in an identity provider group
- request country, based on Cloudflare's data
- device check through the WARP client and its device posture
- session duration limit, from one hour to one week
Setting up login through an identity provider
Access supports login through Google Workspace, GitHub, Azure AD, and a one-time PIN code sent by email without an external provider. For a small team, a One-time PIN is enough: an email with a code arrives at the given address on every login attempt.
For a team sharing a Google account, connect Google as the identity provider under Settings → Authentication and list the allowed mail domains.
Service Tokens for API and CI/CD
When it's not a human but a deploy script or a monitoring tool hitting the protected address, a login form doesn't work. Access provides Service Tokens for this — a Client ID and Client Secret pair passed as request headers.
curl -H "CF-Access-Client-Id: <client_id>" \
-H "CF-Access-Client-Secret: <client_secret>" \
https://admin.example.com/deploy-hookThe token is tied to a separate policy and can be revoked easily without touching the rules for other users.
Summary: checklist before enabling Access
Access gates entry to the panel by checking identity in front of the origin, with no VPN client and no separate port on the server.
- move the admin panel to a separate subdomain and set up an Access application
- hide the origin through Cloudflare Tunnel when a public IP address is not needed
- set up an identity provider or a One-time PIN for login
- describe the policy by email, group, and request country
- issue a Service Token to deploy scripts instead of a shared password