Cloudflare hat die Verfügbarkeit von Zugriffskontrollen für jeden einzelnen Worker angekündigt. Dadurch kann einem Benutzer, einem Softwareagenten oder einem API-Token die Berechtigung erteilt werden, mit einer bestimmten Anwendung zu arbeiten, ohne Zugriff auf die übrigen Ressourcen des Kontos zu erhalten. Der Schritt umfasst vier neue Rollen für die Entwicklerplattform, die dazu dienen, die Überwachung der Anwendung, das Lesen ihrer Inhalte sowie deren Änderung oder vollständige Verwaltung voneinander zu trennen.
Die Kontrollen stehen allen Kunden ab dem 15. September 2026 zur Verfügung und können über das Cloudflare-Dashboard, per API oder mit Terraform eingerichtet werden. Sie lassen sich auf einen einzelnen Benutzer oder auf eine User Group anwenden, sodass alle Mitglieder der Gruppe dieselbe Richtlinie erben.
Vier Berechtigungsstufen
- Metadata Read-Only: Ermöglicht den Einblick in Ressourcenlisten, deren Einstellungen und Überwachungsdaten wie Metriken, Logs und Traces, ohne Zugriff auf Produktinhalte oder Code. Die Rolle eignet sich für die Untersuchung von Störungen, wenn das Lesen des Quellcodes nicht erforderlich ist.
- Content Read-Only: Ermöglicht das Lesen von Produktinhalten wie Worker-Code oder dem Inhalt einer D1-Datenbank, jedoch nicht das Ändern oder Bereitstellen von Änderungen.
- Editor: Ermöglicht das Lesen und Schreiben von Inhalten sowie das Aktualisieren von Einstellungen, erlaubt jedoch nicht das Erstellen oder Löschen von Ressourcen. Cloudflare sieht diese Rolle als geeignete Option für CI/CD-Systeme vor, die Änderungen an einem bestimmten Worker bereitstellen müssen.
- Admin: Gewährt vollständige Kontrolle über die Ressource, einschließlich ihrer Erstellung, Umbenennung und Löschung sowie der Vergabe von Zugriffsrechten an andere Benutzer. Diese Berechtigung kann auf einen einzelnen Worker statt auf das gesamte Konto beschränkt werden.
Was ändert sich in der Praxis?
Das Betriebsteam kann einem Ingenieur oder Agenten die Rolle Metadata Read-Only gewähren, damit dieser Einstellungen, Metriken, Logs und Traces prüft, ohne den Code offenzulegen. Ebenso kann ein Agent den Code mit Content Read-Only überprüfen, ohne ihn bereitstellen oder die Einstellungen der Anwendung ändern zu können.
In CI/CD-Pipelines kann ein API-Token mit der Rolle Editor erstellt und auf einen einzelnen Worker beschränkt werden. Wird die Pipeline falsch konfiguriert oder der Token offengelegt, bleibt seine Fähigkeit auf die Bereitstellung von Änderungen für diese Anwendung beschränkt, ohne den Worker löschen oder andere Anwendungen im Konto ändern zu können. Cloudflare erklärt, dass diese Berechtigungen auf drei Ebenen angewendet werden: auf die gesamte Entwicklerplattform, auf ein bestimmtes Produkt wie Workers oder auf eine bestimmte Ressource wie einen einzelnen Worker.
Wichtige Einschränkungen für Bereiche und Verbindungen
Der Zugriff auf einen Worker allein reicht nicht aus, um eine Route oder eine Custom Domain hinzuzufügen, zu ändern oder zu löschen. Für diese Vorgänge ist neben der Berechtigung Editor für den Worker auch die spezifische Berechtigung Workers Routes für die Zone erforderlich. Diese Trennung ermöglicht die Verwaltung der Weiterleitung des Datenverkehrs zur Anwendung, ohne umfassendere Berechtigungen für die Domaineinstellungen zu gewähren.
Nach der Einrichtung der Route kann ein CI/CD-System weiterhin neue Versionen bereitstellen, solange die Bereitstellung die bestehende Verbindung nicht ändert, ohne Zugriff auf die verbundenen Domains, Datenbanken oder Speicher zu erhalten. Durable Objects verwenden ebenfalls die Berechtigungen des Workers, der sie ausführt: Metadata Read-Only ermöglicht den Zugriff auf ihre Metriken, Logs und Traces, nicht jedoch auf die darin gespeicherten Daten. Für den Zugriff auf Data Studio, das Daten abfragen und ändern kann, ist die Rolle Editor erforderlich.
Fehlermeldungen und ältere Versionen
Cloudflare hat die API-Antworten bei abgelehnten Vorgängen aktualisiert. Sie beschränken sich nicht mehr auf den allgemeinen Fehler 403 Forbidden, sondern enthalten einen Link zu der Dokumentation, in der die erforderliche Berechtigung angegeben ist. Dies soll Benutzern und Agenten helfen, Berechtigungen präzise festzulegen, anstatt sie wahllos auszuweiten.
Das Unternehmen empfiehlt, auf die neuen Rollen statt auf die bisherigen Workers-Berechtigungen umzusteigen. Es hat jedoch keinen Termin für deren Abschaffung angekündigt; die aktuellen Zuweisungen bleiben bestehen, bis eine vorherige Benachrichtigung erfolgt. Cloudflare plant, dasselbe Modell auf weitere Produkte wie D1, R2 und KV auszuweiten, sodass der Zugriff auf eine bestimmte Datenbank oder einen bestimmten Speicherbereich beschränkt werden kann.
Lesart von certi.news
Die tatsächliche Änderung besteht hier nicht lediglich in der Ergänzung einer neuen Administrationsrolle, sondern in der Verlagerung der Kontrolle von der Konto- oder Produktebene auf die Ressourcenebene, mit einer klaren Trennung zwischen Überwachungsdaten, Inhalten und Ausführung. Das ist besonders für Teams wichtig, die Softwareagenten oder automatisierte Bereitstellungspipelines einsetzen, da sich ein Fehler oder ein Token-Leak auf einen einzelnen Worker begrenzen lässt. Die Verwaltung von Routen und Domains erfordert hingegen weiterhin eine separate Berechtigung. Außerdem werden die Unterstützung für D1, R2 und KV weiterhin als späterer Plan und nicht als aktuelle Verfügbarkeit genannt. Dass die bisherigen Berechtigungen ohne angekündigten Abschaffungstermin bestehen bleiben, bedeutet, dass Unternehmen ihre Richtlinien schrittweise überprüfen müssen, statt von einer sofortigen Umstellung auszugehen.