Skip to content

Cloudflare Access Runbook

⚠️ INTERNAL ONLY — Platform + Website Architecture
Not intended for public distribution.

This runbook defines how to protect the internal documentation site (https://docs.example.com) with Cloudflare Access. It aligns with Zero Trust and least privilege principles without implementing Access configuration on your behalf.

  • Recommended default: Google Workspace (enforces corporate MFA by policy).
  • Alternative: GitHub Enterprise (requires SSO + enforced MFA via organization policy).

Document which provider is selected, why, and who administers it. Either option must enforce multi-factor authentication at the identity provider level.

  • Deny by default; only explicitly allowed groups receive access.
  • Require MFA through the chosen identity provider.
  • Session duration: maximum 12 hours.
  • Scope access to least-privilege groups (e.g., rcs-platform-team, rcs-security).
  • Maintain an emergency “break-glass” group with one rotating member; membership requires security approval and is audited.
  • Device posture checks are optional today (deferred), but note them for future enforcement.
  1. Sign in to the Cloudflare Zero Trust dashboard with administrative credentials.
  2. Navigate to Access → Applications and choose Add an application.
  3. Select Self-hosted and set:
    • Application name: RCS Internal Docs
    • Domain: docs.example.com
    • Session duration: 12h
  4. Under Policies, create an Allow policy:
    • Decision: Allow
    • Include: Identity provider groups (e.g., Group: rcs-platform-team, Group: rcs-security)
    • Require: MFA, Email One-time PIN (if IdP MFA cannot be guaranteed)
    • Exclude: None (unless adding explicit deny conditions)
  5. Add a second policy for the break-glass group if required:
    • Include only the emergency group; add a required approval note in the description.
  6. Optionally add a Block policy for non-corporate emails to document the deny-by-default posture.
  7. Save the application. Cloudflare Access will prompt for DNS confirmation if the domain is not already proxied; confirm that docs.example.com points to the Cloudflare Pages project.
  8. Communicate the Access URL (https://docs.example.com) and required group membership process to internal stakeholders.
  • Attempt to reach https://docs.example.com from an unauthenticated browser session; verify a Cloudflare Access prompt appears.
  • Authenticate with an allowed group member; confirm documentation loads successfully.
  • Review Access → Logs to ensure sign-in events are recorded and attributable.
  • Document outcomes in the release checklist before granting wider access.

If Access policies cause outages or misconfiguration:

  1. In the Zero Trust dashboard, disable the specific Access application for docs.example.com.
  2. Notify stakeholders and security immediately; document the time and reason.
  3. Restore the application once policy corrections or group membership issues are resolved.

Keep all Access configuration changes tracked in change management with links to this runbook.