Admin Access Control (Cloudflare Zero Trust)

SOP: Admin Access Control (Cloudflare Zero Trust)

Last Updated: 2026-05-01 Version: 1.0 Tier: Security infrastructure

---

Purpose

Client sites need protected routes — admin dashboards, internal tools, staging URLs — that should only be accessible to the Tekton team and authorized client staff. Cloudflare Zero Trust gates these routes by email domain, requiring login before serving the page. No password storage, no auth code to maintain.

This SOP covers how the system is configured and how to add or remove access.

When to Use:

• Adding a new admin user to an existing client site
• Setting up Zero Trust on a new client clone
• Troubleshooting “I can’t access the admin page” complaints
• Auditing who has access to what

Owner: Web Designer (executes), Nick (approves who gets access) Timeline: 5 minutes per user added. ~30 minutes to wire Zero Trust onto a new client.

Working with Claude on this SOP

The fastest way through this SOP is to paste it into Claude Code (desktop app) and tell Claude what you need:

• “Add jakob@tektongrowth.com to the Zero Trust policy on rc-outdoor.”
• “Set up Zero Trust on the maine-outdoor admin route. Use the same allowed-domains policy as the other Tekton clients.”

If you hit a snag — the user can’t access despite being added, the policy isn’t applying, you get a 403 — describe the issue: “jakob is in the access policy, signed in with the right email, still seeing 403 on rc-outdoor.com/admin.”

Don’t micromanage Claude. Describe the goal and the user. Claude handles the API calls and policy edits.

---

How it works

flowchart LR
  Visitor((Visitor)) -->|requests<br/>example.com/admin| CF[Cloudflare<br/>edge]
  CF --> ZT{Zero Trust<br/>policy match?}
  ZT -->|email allowed| Site[Serve admin page]
  ZT -->|email not allowed,<br/>or not logged in| Login[Cloudflare login screen]
  Login -->|email OTP| OTP[Send 6-digit code<br/>to user's inbox]
  OTP -->|code verified| ZT
  ZT -->|repeated reject| Block[403 Forbidden]

  style ZT fill:#fbbf24,color:#000
  style Site fill:#22c55e,color:#fff
  style Block fill:#dc2626,color:#fff

When a visitor hits a protected route, Cloudflare checks if they have an active session. If not, they’re redirected to a Cloudflare login screen, asked to enter their email, and emailed a 6-digit OTP. If their email matches the access policy, the OTP succeeds and they get a session cookie scoped to that domain.

No passwords. Zero passwords stored anywhere. Just email-based one-time codes.

---

The current setup

Allowed identity providers

• Email OTP (default) — anyone can request a code; only allowed-domain emails get one
• Google SSO (optional, configured per-client) — for clients on Google Workspace

Default access policy

Most client sites use this allow-list:

Allow: emails ending in @tektongrowth.com
Allow: emails ending in @<client-domain>

Specific clients may have additional emails added (the client’s owner, their bookkeeper, etc.).

Protected routes

By default, on every client clone:

• /admin/*
• /dashboard/*
• /internal/*

If a client doesn’t use these paths, no need to add Zero Trust. If they do, the policy is wired during cutover.

---

Common tasks

Task A: Add a new admin user to an existing client

1. Open Cloudflare dashboard → Zero Trust (left sidebar)
2. Access → Applications
3. Find the application for the client (named like <client-slug>-admin)
4. Edit policy → find the “Allow” rule
5. Add the new email to the include list (or the email’s domain if you want all-domain access)
6. Save
7. Test: ask the user to visit the protected URL. They should get the email OTP flow.

Task B: Remove a user

Same steps, but remove the email from the include list. Note: existing sessions stay valid until they expire (typically 24 hours). If immediate removal is needed, use Zero Trust → My Team → Users → find user → Revoke session.

Task C: Wire Zero Trust onto a new client clone

When you’re setting up a clone that has admin paths:

1. Cloudflare dashboard → Zero Trust → Access → Applications → Add an application
2. Choose Self-hosted
3. Configure:
   • Application name: <client-slug>-admin
   • Session duration: 24 hours
   • Application domain: <client-domain> with path /admin
4. Identity providers: select Email OTP + any others the client uses
5. Add a policy:
   • Policy name: “Allowed admins”
   • Action: Allow
   • Include: emails ending in @tektongrowth.com AND emails ending in @<client-domain>
6. Save

Test by visiting <client-domain>/admin in incognito. You should hit the Cloudflare login screen.

Task D: Audit who has access

Cloudflare dashboard → Zero Trust → Logs → Access. Filter by application. Shows every login attempt with timestamp and decision (allow/deny).

For a clean per-client audit:

“List everyone with access to the rc-outdoor admin route based on the Zero Trust policy.”

Claude can pull the policy via the Cloudflare API if given the API token.

---

Troubleshooting

”I can’t access the admin page” — user reports 403

Diagnose:

1. Has the user been added to the access policy? Check the application policy in dashboard.
2. Is the user signing in with the email that’s on the allow list? (Common mistake: Tekton email vs. personal Gmail)
3. Is the email OTP arriving? Check spam folder. Cloudflare emails come from noreply@<your-team>.cloudflareaccess.com.
4. Is the OTP being entered within 5 minutes? Codes expire.
5. Has the user just been added? Allow 1-2 minutes for the policy to propagate.

If all of the above look correct: check the Access logs for the user’s email. The deny reason will tell you what triggered the rejection.

”Loop redirect” — page keeps redirecting between login and the protected URL

Usually means cookies are blocked in the user’s browser. Have them try in incognito with cookies enabled. If that works, they have a third-party cookie blocker on their main browser.

”Email OTP isn’t being sent”

Cloudflare rate-limits OTP requests. If a user has requested 5+ codes in a short time, they’re blocked for ~10 minutes. Wait it out.

If consistently failing: check Zero Trust → Settings → Authentication → confirm Email OTP is enabled.

”I removed someone but they can still access”

Sessions persist until expiry (default 24h). Force-revoke at Zero Trust → My Team → Users.

---

What NOT to do

• Don’t share OTP codes between team members. Each person logs in with their own email.
• Don’t add * as an allowed email domain. That defeats the entire system.
• Don’t disable Zero Trust temporarily without re-enabling. “I’ll add it back later” never happens.
• Don’t put production credentials behind Zero Trust as the only protection. Zero Trust is access control, not data security. Sensitive data still needs application-level auth.

---

Definition of done

When wiring Zero Trust onto a new client:

• Application configured in CF dashboard with the right domain + path
• Allow policy includes Tekton + client domain
• Tested in incognito: protected route shows login screen
• Tested with allowed email: OTP flow works, page loads after auth
• Tested with non-allowed email: gets 403 after OTP entry
• Documented in the per-client log

---

Version Control

• v1.0 (2026-05-01): Initial SOP. Reflects the Zero Trust setup wired during the clone-gate phase.