Skip to content

Cloudflare Access

All public heezy sites sit behind Cloudflare Zero Trust Access, using Google OAuth as the only identity provider.

Terraform: terraform-heezy/environments/production/cloudflare/access.tf Last Updated: 2026-08-11

Protected Sites

Application name Domain Purpose
Heezy Finance finance.heezy.info Spending analytics
Heezy Receipts receipts.heezy.info Receipt OCR and upload
Heezy Statements statements.heezy.info Statement file upload
Heezy CS1.6 Leaderboard cs16.heezy.info Game statistics
Heezy Blog heezy.blog Personal blog
Heezy Docs docs.heezy.info This site
Heezy Home heezy.info Landing page
emulatorjs emulatorjs.trentnielsen.me Browser emulator

Authentication

Setting Value
Provider Google OAuth, pinned via allowed_idps = [google_idp_id]
Allowed emails trentnielsen84@gmail.com, brdrgrl18@gmail.com (local.allowed_emails)
Session duration 24h
auto_redirect_to_identity true — CF silently checks the existing Google session, no prompt if already signed in

Pinning allowed_idps matters. emulatorjs was running with allowed_idps = [], which means every enabled IdP including the account's one-time-PIN provider. It was adopted into Terraform via import blocks and pinned to Google to match the rest.

Two Policies Per App

Every heezy.info app has the same pair, evaluated by precedence:

Precedence Name Decision Include
10 Bypass home IP bypass 76.112.11.44/32 (local.home_ip)
20 Allow family allow local.allowed_emails

The bypass means requests from the home WAN IP reach the app with no login. Everything else must prove identity with Google.

emulatorjs has no bypass policy, on purpose

LAN clients resolve emulatorjs.trentnielsen.me to the SWAG VIP and never traverse the Cloudflare edge, so a bypass would only widen who can reach it without proving identity.

Public Exceptions

Intentionally not behind Access:

  • oauth.heezy.info — the OAuth callback endpoint, must be publicly reachable for the Google redirect
  • tos.heezy.info — Terms of Service
  • privacy.heezy.info — Privacy policy

Resource Names

Deprecated resource types, deferred on purpose

cloudflare_access_application and cloudflare_access_policy are deprecated in cloudflare provider v4. The rename to cloudflare_zero_trust_access_* needs provider v5.

This was attempted and reverted. Neither moved{} blocks nor terraform state mv work for a cross-type rename in provider v4 — the provider cannot refresh the new type, so the plan shows destroy plus create on every Access app. Deferred until the provider upgrade.

Deployment

Access lives in the shared terraform-heezy repo, not a separate cloudflare-terraform repo.

edit terraform-heezy/environments/production/cloudflare/access.tf
  → git push gitea <branch>, open a PR (branch protection is on)
  → merge to main
  → .gitea/workflows/ terraform plan + apply on the act-runner

Careful with Access policies

An incorrect policy can lock you out. Review the plan before merging. The home-IP bypass is the practical safety net: from the house you still reach every app even if the allow policy breaks.

Troubleshooting

Locked out

  1. From the home network the bypass policy should still let you in. Try that first
  2. Check the app and its policies in the Cloudflare Zero Trust dashboard
  3. If a policy was destroyed, restore it by re-running the pipeline

Session expired

Sessions last 24h. Re-authenticate with Google.

New user access

Add the address to local.allowed_emails in access.tf, push a branch, open a PR, merge. Every app picks it up, since they all reference the same local.