Locking Down Django Admin with Cloudflare Access at Zero Cost!

1. Why your /admin endpoint needs Zero‑Trust protection

The Django admin console is a high‑value target: a single leaked credential can hand an attacker the keys to your application. Traditional network controls (VPNs, IP allow‑lists) often break when teams are distributed or on the move. A Zero‑Trust Network Access (ZTNA) model puts strong identity and device checks in front of every request no matter where users are.

2. Cloudflare Access in a nutshell

Cloudflare Access is Cloudflare’s ZTNA product. On the Free plan you can protect any number of self‑hosted applications for up to 50 users, forever – plenty for most teams that need Django admin access. Cloudflare Access sits between the Internet and your app, authenticating each request with your chosen identity provider (Google Workspace, Azure AD, Okta, GitHub, or Cloudflare’s own OTP).

3. Step‑by‑step: putting Django admin behind Cloudflare Access

1. Get onto Cloudflare
   • Add your domain to Cloudflare and switch the DNS record for your Django site to “Proxied” (orange cloud).
   • If you can’t expose port 80/443 directly, install cloudflared and create a Cloudflare Tunnel to your internal server.
2. Create an Access application
   • Zero Trust dashboard → Access ▸ Applications ▸ Add an application
   • Type: Self‑hosted
   • Name: Django Admin
   • Domain: admin.example.com or example.com/admin/* (path‑based works too).
3. Define an Allow policy
   • Choose your IdP.
   • Add allowed users or groups (e.g., anyone with @your‑company.com).
   • Set session duration (e.g., 8 h).
4. (Optional) Hide the endpoint
   • In urls.py change path("admin/", admin.site.urls) to something less guessable: path(“secure-ops-portal/”, admin.site.urls)
   • Update the Access rule to the new path.

4. Enforcing phish‑proof FIDO2 security keys

Cloudflare Access lets you mandate hardware‑based MFA (YubiKey, Feitian, Google Titan, Touch ID, Windows Hello).

1. Zero Trust dashboard → Settings ▸ Authentication ▸ Security Keys (FIDO2/WebAuthn).
2. Flip Require security keys to On.
3. For granular control, add a “Require hard key” rule inside your Django Admin Access policy. Any login without a registered key is blocked – even if the IdP would otherwise allow fallback OTP.
4. Ask users to register at least two keys for redundancy (primary + backup).

Why FIDO2?

• Phishing‑resistant – keys sign the login request bound to the site’s origin.
• Fast – tap the key; no codes to type.
• Works offline – no SMS or authenticator app required.

5. Extra defense‑in‑depth tips

• Enforce HTTPS everywhere:
  
  SECURE_SSL_REDIRECT = True
  CSRF_COOKIE_SECURE = True
  SESSION_COOKIE_SECURE = True
  
• Lockout / rate‑limit local logins with django‑axes or django‑defender.
• Limit superusers – give most staff a custom, least‑privilege admin role.
• Keep Django current and apply security releases promptly.
• Audit Cloudflare logs (Zero Trust ▸ Access ▸ Logs) for anomalies.
• Back‑channel alerts – send Access audit events to SIEM or Slack for real‑time visibility.

6. Cost check & next steps

Because Cloudflare counts unique human users, not requests, most small and mid‑sized engineering teams stay under the 50‑seat free tier indefinitely. If you grow past that, you can upgrade per user without touching your architecture.

Bottom line: In under an hour you can move Django admin behind Cloudflare’s global edge, add single sign‑on, and require un‑phishable FIDO2 authentication – all without opening your wallet. Lock it down now, and keep shipping features with confidence.