Skip to main content

Cloudflare Access Setup

This portal is technically public (the GitHub repo + GitHub Pages serve it openly), but we gate it with Cloudflare Access so only allowed email addresses can read the deployed site. Free tier covers up to 50 users.

Why public repo + Cloudflare Access instead of private repo? GitHub Pages on the free plan requires public repos. Going private would mean either GitHub Pro ($4/user/mo, recurring forever) or moving to Cloudflare Pages (more setup). Cloudflare Access in front of a public-repo Pages site gives us the same effective access control at $0.

The trade-off: the markdown SOURCE is publicly readable on github.com/sidgk/ka26-docs. The DEPLOYED SITE (with search index, navigation, all pages stitched together) requires login. So: never put real secrets in the docs. Reference 1Password for credentials, never paste them.

Setup steps (one-time, ~10 min)​

1. Sign up for Cloudflare (free)​

2. Add ka-26.com to Cloudflare DNS​

  • Cloudflare dashboard → "Add a Site" → enter ka-26.com
  • Pick the Free plan
  • Cloudflare scans existing DNS records (the ones in Hostinger now)
  • Cloudflare gives you 2 nameservers (e.g., kira.ns.cloudflare.com, walt.ns.cloudflare.com)
  • Go to Hostinger → Domain → DNS / Nameservers → switch from default Hostinger NS to the 2 Cloudflare ones
  • Wait 30 min for propagation (dig ka-26.com NS should show the Cloudflare ones)

3. Verify existing DNS still works​

After nameserver propagation, ka-26.com, docs.ka-26.com (once we set it up), and email (MX records) should all resolve via Cloudflare. Cloudflare imports your existing records from Hostinger automatically.

4. Add docs.ka-26.com CNAME → sidgk.github.io​

  • Cloudflare dashboard → ka-26.com → DNS → Records
  • Add CNAME: Name=docs, Target=sidgk.github.io, Proxy status=Proxied (orange cloud)

5. Set up Cloudflare Access (Zero Trust)​

  • Cloudflare dashboard → Zero Trust (icon in left sidebar)
  • First time: pick a team name (e.g., ka26) — your portal becomes ka26.cloudflareaccess.com
  • Settings → Authentication → Login methods: enable "One-time PIN" (sends a 6-digit code to email — simplest, no Google Workspace required) AND/OR "Google" (uses Google OAuth)

6. Create an Access Application for the docs​

  • Zero Trust → Access → Applications → Add an application
  • Choose Self-hosted
  • Application name: KA26 Docs
  • Session duration: 24 hours (re-auth daily)
  • Application domain: docs.ka-26.com
  • Continue to policies

7. Define who can access​

  • Policy name: Team
  • Action: Allow
  • Configure rules → Selector = "Emails" → enter:
    • siddugkattimani@gmail.com
    • any team member emails (one per line)
  • (Optional) Add a second selector "Emails ending in" @ka-26.com to auto-allow anyone with a Workspace account

Save the policy + the application.

8. Test​

  • Open an incognito window → https://docs.ka-26.com
  • You should see the Cloudflare Access login screen, NOT the docs
  • Enter your email → check inbox for the OTP → enter it → docs load

If you see the docs without auth, the application domain is wrong — double-check step 6.

Adding/removing team members​

  • Zero Trust → Access → Applications → KA26 Docs → Policies → edit the Team policy → add/remove emails

Audit log​

Zero Trust → My Team → Logs shows every login attempt + email + result. Useful for "did this person access docs in the last 30 days?"

Cost​

  • Cloudflare DNS: free forever
  • Cloudflare Access: free up to 50 users (we have ~5)
  • Total: $0/month

What NOT to put in the docs​

Even with Access in front:

  • ❌ Real production credentials (DB passwords, API keys, JWT secrets) — put in 1Password
  • ❌ Customer PII (names, phones, emails) — query the DB live, don't paste examples
  • ❌ Payment gateway secrets

✅ Safe: env var NAMES, file paths, code snippets, architecture diagrams, business logic descriptions