Cloudflare hat die Einführung von Cloudflare Access for Workers angekündigt, einer Tool-Sammlung, mit der sich eine Access-Richtlinie direkt mit einem Worker oder mit allen Workers-Anwendungen innerhalb eines Kontos verbinden lässt. Durch diese Verbindung werden Anwendungen standardmäßig hinter einer Unternehmensanmeldung geschützt, ohne darauf angewiesen zu sein, dass sich jeder Entwickler separat an die Einrichtung von Zugriffskontrollen erinnert.
Der Schritt erfolgt vor dem Hintergrund, dass Beschäftigte mithilfe von KI-Tools Anwendungen schneller erstellen und bereitstellen können. Cloudflare ist der Ansicht, dass diese Geschwindigkeit auch dazu führen kann, dass interne Anwendungen oder private Daten versehentlich im öffentlichen Internet veröffentlicht werden. Deshalb wurden die neuen Tools so konzipiert, dass der Schutz von auf Workers gehosteten Anwendungen Teil des Bereitstellungsprozesses selbst wird.
Schutz der Anwendung unabhängig von der Zugriffsmethode
Wenn Access für einen Worker aktiviert wird, erzwingt Cloudflare die Authentifizierung, bevor eine Anfrage den Anwendungscode erreicht. Dies gilt unabhängig davon, ob der Nutzer über eine benutzerdefinierte Domain, einen Pfad, eine Subdomain auf workers.dev oder eine Vorschau-URL auf die Anwendung zugreift.
Bisher wurde Access auf Hostnamenebene eingerichtet. Das bedeutete, dass für jede Domain, über die ein Nutzer auf einen Worker zugreifen konnte, separate Richtlinien erstellt werden mussten. Beim Hinzufügen einer neuen benutzerdefinierten Domain musste die Richtlinie zunächst aktualisiert werden; andernfalls konnte diese Domain ohne Authentifizierung erreichbar sein. Nun wird die Richtlinie direkt mit dem Worker verknüpft, wodurch die zugehörigen Domains und URLs automatisch geschützt werden.
Der Schutzbereich kann je nach Bedarf ausgewählt werden:
- Nur Vorschau-URLs schützen, einschließlich workers.dev-URLs oder benutzerdefinierter Domains, die für Vorschauen verwendet werden.
- Alle mit der Anwendung verbundenen Hostnamen schützen, einschließlich benutzerdefinierter Domains, Pfade, workers.dev-Domains und Vorschau-URLs.
Standardrichtlinie auf Kontoebene
Teams, die eine große Anzahl von Workers-Anwendungen verwalten, können eine Access-Richtlinie einmalig auf Kontoebene konfigurieren. Danach werden alle bestehenden und zukünftigen Anwendungen ab dem Zeitpunkt ihrer Erstellung privat, wobei festgelegt werden kann, ob die Richtlinie den Datenverkehr von Vorschau-URLs, Produktionsdatenverkehr oder beides abdecken soll.
Die Option „Nur Vorschauen“ kann für Anwendungen geeignet sein, die in der Produktionsumgebung öffentlich bleiben sollen, während die Offenlegung von Versionen in der Entwicklung verhindert wird. Cloudflare ermöglicht außerdem, die Kontorichtlinie für einen bestimmten Worker zu überschreiben, wenn dieser öffentlich zugänglich sein soll.
Wer keine umfassende Richtlinie benötigt, kann Access auch direkt auf einen einzelnen Worker anwenden. Die neue Access-Registerkarte in der Worker-Oberfläche zeigt die für die Anwendung geltenden Richtlinien an. Wenn mehrere Richtlinien vorhanden sind, hat die spezifischste Richtlinie Vorrang, und zwar in folgender Reihenfolge: Hostnamenrichtlinien, dann Workerrichtlinien, dann Kontorichtlinien.
Nutzeridentität im Anwendungscode
Access ermöglicht außerdem, die Identität des Nutzers zu erkennen, der jede Anfrage an die Anwendung sendet, einschließlich seiner E-Mail-Adresse, seines Namens und seiner Gruppen. Cloudflare zufolge können diese Daten zur Personalisierung von Inhalten, zur Durchsetzung von Berechtigungen oder zur Protokollierung der Aktivitäten einzelner Nutzer verwendet werden.
Die Identitätsinformationen erscheinen im ctx-Kontextobjekt des Workers, insbesondere über ctx.access. Die Anwendung kann ctx.access.getIdentity() aufrufen, um die Identität des authentifizierten Nutzers abzurufen, ohne die JSON-Web-Token-Prüfung manuell durchführen zu müssen, etwa durch das Parsen des Tokens, die Überprüfung seiner Signatur und das Auslesen seiner Claims.
Access unterstützt die Anbindung des bestehenden Identitätsanbieters einer Organisation. Außerdem kann der Zugriff anhand bestimmter E-Mail-Adressen, E-Mail-Domains oder Gruppen eingeschränkt werden. Agenten kann der Zugriff über Servicetokens gewährt werden.
Lokales Testen und interne Plattformen
Das Identitätsverhalten kann lokal mit wrangler dev getestet werden, indem die Access-Konfiguration zur Datei wrangler.jsonc hinzugefügt wird, um einen authentifizierten Nutzer zu simulieren. Dadurch kann der Entwickler die E-Mail-Adresse in der Konfiguration ändern und vor der Bereitstellung überprüfen, ob für jeden Nutzer die passenden Inhalte angezeigt werden.
Cloudflare hat außerdem ein Open-Source-Beispiel für eine interne Plattform veröffentlicht, über die sich statische Websites per Drag-and-drop bereitstellen lassen, wobei jeder bereitgestellte Worker standardmäßig privat ist. Diese Architektur nutzt Workers for Platforms: Der Datenverkehr der Anwendungen innerhalb des Namespace wird über einen einzigen verteilten Worker geleitet. Wird Access auf diesem Worker aktiviert, sind die darüber bereitgestellten Anwendungen standardmäßig privat.
Verfügbarkeit und technische Architektur
Die Funktion ist ab sofort für alle über das Dashboard verfügbar. Zum Einstieg stellt Cloudflare eine Dokumentation zu Cloudflare Access for Workers bereit. Die neue Möglichkeit basiert auf FL2, einem modularen, mit Rust entwickelten Proxy, der die Edge-Infrastruktur von Cloudflare ausführt.
Um Access auf Workerebene statt auf Hostnamenebene zu ermöglichen, hat Cloudflare das Routing von Workers von deren Ausführung getrennt und die Routinglogik in eine Phase vor Access verlagert. Nach Angaben des Unternehmens half ihm das modulare FL2-System mit seinen definierten Modulen und geordneten Phasen bei der Umsetzung dieser Änderung: Jeder Teil legt seine Eingaben und Ausgaben auf konsistente Weise offen, wodurch der Compiler während der Umstrukturierung fehlerhafte Wechselwirkungen zwischen den Phasen erkennen konnte.