Schritt 6: Cloudflare Access einrichten
Ohne diesen Schritt ist deine Doku öffentlich erreichbar. Cloudflare Access setzt eine Login-Seite davor, sodass nur berechtigte Personen Zugriff haben — ohne VPN, besser als Basic Auth.
Voraussetzung
- Die Seite ist bereits deployed (Schritt 5).
- Cloudflare Zero Trust ist aktiviert (Free-Tier reicht für kleine Teams, max. 50 Nutzer).
Zero Trust aktivieren
- Gehe zu one.dash.cloudflare.com (Zero Trust Dashboard).
- Aktiviere Zero Trust Free — der Free-Plan kostet nichts. Cloudflare fragt nach einer Zahlungsmethode, diese wird aber nicht belastet, solange du unter 50 Nutzern bleibst. Es gibt keine versteckten Kosten im Free-Tier.
Login-Methode (Identity Provider) hinzufügen
Bevor du eine Application anlegst, muss mindestens eine Login-Methode konfiguriert sein. Standardmäßig ist nur „Cloudflare" verfügbar — das reicht nicht.
- Im Zero Trust Dashboard die Suchleiste oben nutzen und nach „Login methods" oder „Authentication" suchen. Die Menüstruktur ändert sich gelegentlich — die Suche ist der zuverlässigste Weg.
- Add new → eine Methode wählen:
One-time PIN (empfohlen zum Start)
Keine Konfiguration nötig. Der Nutzer gibt seine E-Mail ein, bekommt einen Einmalcode per Mail, fertig. Am einfachsten.
GitHub
Braucht eine GitHub OAuth App. Etwas mehr Aufwand als One-time PIN, aber dafür ein smootheres Login-Erlebnis.
Schritt A: Team-Namen herausfinden
Den brauchst du für die Callback-URL. Du findest ihn im Zero Trust Dashboard:
- In der URL:
https://one.dash.cloudflare.com/<account-id>/<team-name>/... - Oder unter Settings → General → Team name
Falls du noch keinen hast, wirst du beim ersten Zugriff aufgefordert, einen zu vergeben.
Schritt B: GitHub OAuth App erstellen
- Gehe zu GitHub → Settings → Developer settings → OAuth Apps → New OAuth App.
- Ausfüllen:
| Feld | Wert |
|---|---|
| Application name | Cloudflare Access |
| Homepage URL | https://deine-domain.de |
| Authorization callback URL | https://<dein-team-name>.cloudflareaccess.com/cdn-cgi/access/callback |
- Klicke auf Register application.
- Du siehst jetzt die Client ID — kopiere sie.
- Klicke auf Generate a new client secret — kopiere das Client Secret sofort (wird nur einmal angezeigt).
Schritt C: In Cloudflare eintragen
- Zurück im Zero Trust Dashboard: Login methods → Add new → GitHub.
- Trage Client ID und Client Secret ein.
- Unique name: frei wählbar, z. B.
GitHub. - Proof Key for Code Exchange (PKCE): aus lassen.
- Enable Device Flow: aus lassen (nur für CLI-Logins relevant, nicht für Web).
- Speichern.
Häufiger Fehler
Unable to find your Access organization! / Invalid URL / team name
→ Der Team-Name in der Callback-URL stimmt nicht. Prüfe den exakten Team-Namen im Zero Trust Dashboard (Schritt A) und aktualisiere die Authorization callback URL in der GitHub OAuth App.
Braucht Google Cloud OAuth Credentials (Client ID + Secret) — deutlich aufwendiger einzurichten. Für den Start besser One-time PIN oder GitHub nehmen.
Application anlegen
- Access → Applications → Add an application → Self-hosted.
- Konfiguriere:
| Feld | Wert |
|---|---|
| Application name | Interne Dokumentation |
| Application domain | Subdomain + Domain wählen (z. B. docs + deine-domain.de) |
| Session Duration | 1 week (nach Bedarf) |
- Klicke auf Next.
Policy anlegen
Hier legst du fest, wer Zugriff bekommt.
| Feld | Wert |
|---|---|
| Policy name | Team-Zugriff |
| Action | Allow |
| Include → Selector | Emails |
| Wert | Einzelne E-Mail-Adressen eintragen |
Einzelne E-Mails statt Domain-Wildcard — sicherer, weil nur explizit eingetragene Personen Zugriff haben. Bei einer Domain-Wildcard (@firma.de) hätte jeder mit einer E-Mail dieser Domain Zugriff — auch wenn ein Account kompromittiert wird.
Wenn du GitHub als Login-Methode nutzt, prüft Access die E-Mail-Adresse deines GitHub-Accounts gegen die Include-Regel. Die E-Mail muss also übereinstimmen.
Testen
- Öffne deine Doku-URL in einem privaten/Inkognito-Fenster.
- Du solltest eine Cloudflare-Login-Seite sehen.
- Logge dich mit einer berechtigten E-Mail-Adresse ein.
- Nach dem Login siehst du die Dokumentation.
Auch die pages.dev-Domain absichern
Deine Access-Policy schützt nur die eingetragene Domain. Die Standard-URL interne-doku.pages.dev ist weiterhin öffentlich erreichbar. Erstelle eine zweite Access-Application mit Domain interne-doku.pages.dev und derselben Policy.
Prüfe auch, ob Preview-Deployments (z. B. abc123.interne-doku.pages.dev) geschützt sind. Falls nicht, erstelle eine Application mit Wildcard-Domain: *.interne-doku.pages.dev.
Hinweis zum Datenschutz
Die Inhalte liegen unverschlüsselt bei Cloudflare. Für interne Prozess-Dokumentation meist akzeptabel. Bei sensiblen Infrastruktur-Geheimnissen besser self-hosted hinter Tailscale.