Cloudflare Worker: Rechte für Client-Deployments begrenzen

Seit dem 15. September 2026 lassen sich die vier Rollen bei Cloudflare für jeden einzelnen Cloudflare Worker vergeben. So wird aus einem gemeinsam genutzten Deployment-Zugang eine klare Grenze pro Kunde. Eine Agentur kann dem CI-Job eines Kunden damit erlauben, genau einen vorhandenen Worker bereitzustellen – ohne zugleich Löschrechte oder Zugriff auf alle anderen Workers im Konto zu vergeben, sofern keine weiter gefasste Richtlinie diese Grenze wieder aufhebt.

Beim Cloudflare Worker entscheidet der Geltungsbereich

Eine Berechtigung besteht aus zwei Teilen. Die Rolle legt fest, welche Aktionen erlaubt sind. Der Geltungsbereich bestimmt, für welche Ressourcen sie gelten.

Cloudflare erlaubt es jetzt, eine Worker-Rolle für Teammitglieder, Benutzergruppen, Agenten oder API-Tokens auf einen einzelnen Worker zu begrenzen. Dieselbe Rolle kann weiterhin für sämtliche Workers gelten, sie muss es aber nicht mehr.

Auf den ersten Blick ist das nur eine kleine Verwaltungsfunktion. Für Studios und Agenturen, die mehrere Kunden in einem Cloudflare-Konto betreuen, verändert sie jedoch die Übergabe: Die Deployment-Zugangsdaten für Kunde A können nun am Worker von Kunde A enden.

Die Veröffentlichung vom 15. September steht allen Kunden zur Verfügung und lässt sich über das Dashboard, die API oder Terraform nutzen.

Die Workers-Rollenreferenz führt diese vier Rollen auf:

Diese Trennung ist sinnvoll, denn Fehlersuche, Codeprüfung, Auslieferung und Löschen des Dienstes sind vier verschiedene Aufgaben. Sie sollten nicht automatisch dieselben Zugangsdaten erben.

Cloudflares frühere Workers-Berechtigungen galten für das gesamte Konto. Das neue Modell kann für die Developer Platform, für alle Workers oder nur für einen vorhandenen Worker eingerichtet werden. Eine produktweite Workers-Richtlinie umfasst jeden aktuellen und künftigen Worker. Eine Richtlinie pro Worker gilt ausschließlich für die ausgewählten Workers.

Eine strukturelle Grenze bleibt: Der Zugriff lässt sich nicht auf einen Worker beschränken, der noch gar nicht existiert. Zum Erstellen eines neuen Workers ist weiterhin Admin auf Produktebene erforderlich.

Was sich bei der Übergabe an Kunden ändert

Angenommen, eine kleine Agentur betreibt für jeden Kunden einen eigenen Worker. Ihr Deployment-Workflow muss neue Versionen von client-a-api veröffentlichen. Er muss weder Workers anlegen noch diesen Worker löschen oder client-b-checkout berühren.

Vor dieser Veröffentlichung galten die üblichen Workers-CI-Berechtigungen, die Cloudflare inzwischen als Legacy kennzeichnet, für das gesamte Konto. Damit gab es zwei saubere Möglichkeiten: weitreichende Zugangsdaten akzeptieren oder den Kunden in ein separates Konto verschieben. Der individuelle Worker-Geltungsbereich eröffnet eine dritte: Die Kontostruktur bleibt bestehen, doch das Deployment-Token erhält nur für client-a-api die Rolle Editor.

Am Abomodell ändert sich nichts, weil die Steuerung auf Worker-Ebene allen Kunden offensteht. Die betrieblichen Folgen ändern sich durchaus.

Die Rechnung lässt einen wichtigen Zielkonflikt außen vor: Zwölf auf einzelne Kunden begrenzte Zugangsdaten bedeuten mehr Geheimnisse, die ausgegeben, gespeichert und rotiert werden müssen, als ein gemeinsam genutztes Token. Der Vorteil liegt nicht in weniger Zugangsdaten, sondern in einer kleineren Zahl von Projekten, die bei Ausfall oder Kompromittierung eines Zugangs untersucht werden müssen.

Ein Solo-Gründer mit nur einem Worker und ohne gemeinsam genutzten Deployment-Zugang wird kaum einen Unterschied bemerken. Dasselbe gilt für Teams, die ihrer Plattformgruppe bewusst die Kontrolle über alle Workers geben. Relevant wird die Änderung, sobald mehrere Personen, Kunden oder automatisierte Jobs ein Cloudflare-Konto teilen, aber nicht denselben Auswirkungsradius haben sollen.

Einen Cloudflare Worker mit genau den nötigen Rechten deployen

Für die erste saubere Übergabe eignet sich ein vorhandener Worker mit stabiler Route oder Custom Domain. So bleiben das Anlegen des Workers und Änderungen an der Domain-Verknüpfung außerhalb des Deployment-Jobs.

1. 1

   Erst die Aufgabe festhalten, dann die Rolle wählen

   Ein Satz genügt: „Dieser Workflow stellt neue Versionen des vorhandenen Workers client-a-api bereit.“

   Diese Aufgabe spricht für Editor mit individuellem Worker-Geltungsbereich. Muss der Job einen neuen Worker anlegen, benötigt er Admin auf Produktebene. Soll er eine Route oder Custom Domain hinzufügen, ändern oder entfernen, braucht er außerdem Workers Routes Write für jede betroffene Zone.

2. 2

   Ein kontoeigenes API-Token erstellen

   Öffnen Sie in Cloudflare Manage Account > Account API Tokens und erstellen Sie ein kontoeigenes Token. Wählen Sie als Geltungsbereich Specified Workers, markieren Sie client-a-api und weisen Sie anschließend Editor zu.

   Für den Workflow sollte ein kontoeigenes Token statt des persönlichen Tokens eines Benutzers eingesetzt werden. Cloudflare beschreibt kontoeigene Tokens als Dienstidentitäten für dauerhafte Integrationen. Das Deployment läuft deshalb weiter, wenn die Person, die es eingerichtet hat, das Unternehmen verlässt. Zum Erstellen oder Aktualisieren eines solchen Tokens ist die Berechtigung Super Administrator nötig.

3. 3

   Wrangler mit diesem Token ausführen

   Speichern Sie das Token im Secret Store des Deployment-Systems. Cloudflare dokumentiert für Wrangler die folgenden Umgebungsvariablen:

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   Führen Sie den Befehl im konfigurierten Projekt des vorhandenen Workers aus. wrangler login ist hier kein Ersatz, weil dessen OAuth-Ablauf die granulare Autorisierung derzeit nicht unterstützt.

4. 4

   Umstellen und anschließend den breiten Zugriff entfernen

   Stellen Sie über das neue Token eine unkritische Version bereit und prüfen Sie, ob der vorgesehene Worker aktualisiert wurde. Vergewissern Sie sich, dass dem Token weder eine Workers-Rolle auf Produktebene noch ein unbeteiligter Ressourcengeltungsbereich zugewiesen ist.

   Entfernen Sie danach die alten, weitreichenden Deployment-Zugangsdaten aus diesem Workflow. Beide Zugänge während des Tests parallel vorzuhalten ist sinnvoll. Beide auch nach dem Test beizubehalten, hebt die neue Grenze wieder auf.

Damit ist die Übergabe für ein routinemäßiges Deployment abgeschlossen. Der CI-Job des Kunden darf den Worker aktualisieren, Code hochladen und bereitstellen, einen Rollback ausführen, den Worker umbenennen und seine Secrets verwalten, weil all diese Aktionen zur Rolle Editor gehören. Er darf den Worker nicht löschen, und die Richtlinie für diesen einzelnen Worker gewährt keinen Zugriff auf andere Workers.

Vier Aufgaben, vier passende Richtlinien

Ein Support-Agent, der nur Belege benötigt

Weisen Sie einem Agenten für die Fehlersuche Metadata Read-Only für den betroffenen Worker zu. Er kann Einstellungen, Metriken, Logs und Traces untersuchen, ohne den Quellcode zu lesen oder den Dienst zu verändern.

So kann ein Support-Workflow Belege sammeln, ohne unbemerkt zugleich zum Codeprüfungs- oder Deployment-Workflow zu werden. Dieselbe Rolle reicht für wrangler tail auf diesem Worker aus.

Ein externer Entwickler prüft einen Kunden-Build

Ein Auftragnehmer erhält Content Read-Only für den Worker des Kunden. Damit kann er den bereitgestellten Quellcode und die Einstellungen prüfen, aber weder Änderungen vornehmen noch ein Deployment ausführen.

Das schafft eine klarere Grenze für die Prüfung. Nur weil der Prüfer verstehen muss, was produktiv läuft, ist noch keine Editor-Rolle erforderlich.

Eine kundenspezifische CI-Pipeline

Das kontoeigene Token erhält Editor für genau einen vorhandenen Worker. Es kann Versionen veröffentlichen und zurücksetzen, ohne den Worker zu löschen oder andere Workers zu erreichen.

Für die Übergabe durch eine Agentur ist das die überzeugendste Variante, weil die Zugangsdaten dem Workflow und nicht einem Mitarbeiter gehören. Wenn außerdem Browser-Agenten für Kundenprojekte laufen, sichern Cloudflares Kontrollen für freigegebene Hosts eine andere Seite derselben Grenze ab: wohin der Browser navigieren darf. Diese Veröffentlichung regelt dagegen, welchen Worker die Deployment-Identität verändern darf.

Ein Plattformverantwortlicher verwaltet den Lebenszyklus

Admin sollte dem Teammitglied oder der Automatisierung vorbehalten bleiben, die tatsächlich Löschrechte benötigt. Admin auf Produktebene bleibt bei der verantwortlichen Stelle, die Workers anlegt; anschließend wird der fertige Worker an die enger gefassten Richtlinien für den täglichen Betrieb übergeben.

Damit entsteht eine sichtbare Trennung zwischen Änderungen am Lebenszyklus und der routinemäßigen Auslieferung. Ein Deployment-Job braucht nicht dieselben Befugnisse wie die Person, die Kundendienste anlegt und außer Betrieb nimmt.

Die Grenze wird enger, ist aber keine vollständige Isolation

Der zentrale Vorteil ist real. Dennoch kann „nur ein Worker“ zu einer gefährlichen Vereinfachung werden.

Durable Objects erfordern dieselbe Sorgfalt. Sie besitzen keine eigenen Rollen oder Geltungsbereiche, sondern übernehmen den Zugriff des Workers, der sie implementiert. Metadata Read-Only schließt Metriken, Logs und Traces eines Durable Objects ein, jedoch keinen Zugriff auf gespeicherte Daten. Editor erfüllt dagegen auch die dokumentierte Voraussetzung, um über Data Studio Daten in einem SQLite-basierten Durable Object abzufragen oder zu verändern.

Routes bilden eine weitere, eigenständige Grenze. Editor reicht aus, um eine neue Version bereitzustellen, solange eine vorhandene Route oder Custom Domain unverändert bleibt. Änderungen an dieser Verknüpfung erfordern zusätzlich Workers Routes Write für jede betroffene Zone. Cloudflare weist außerdem darauf hin, dass Custom Domains derzeit keine Rollen pro Worker unterstützen.

Außerdem summieren sich Cloudflare-Berechtigungen. Eine eng gefasste, direkt zugewiesene Richtlinie hebt keine weitreichende Richtlinie auf, die über eine Benutzergruppe geerbt wurde. Die Ansicht Members zeigt direkte Berechtigungen; geerbte Gruppenrichtlinien müssen im Tab Groups geprüft werden. Ohne diese Kontrolle kann die Oberfläche zwar die gewünschte enge Richtlinie anzeigen, während die tatsächlich wirksamen Berechtigungen weitreichend bleiben.

Wer jetzt handeln sollte

Noch in dieser Woche besteht Handlungsbedarf, wenn ein Konto mehrere Kunden-Workers enthält und eine Person, ein Agent oder ein CI-Job für eine Aufgabe an nur einem Worker weiterhin eine Berechtigung für alle Workers besitzt. Am größten ist der Nutzen, wenn der Worker bereits existiert und seine Domain-Verknüpfungen bei routinemäßigen Deployments unverändert bleiben.

Mit der Einschränkung des Tokens sollte noch gewartet werden, wenn der Workflow Workers anlegt, Routes oder Custom Domains verändert oder direkten Zugriff auf gebundene Datenprodukte benötigt. Erfassen Sie zuerst diese Aktionen, sonst scheitert das nächste Deployment mitten im Ablauf.

Nicht betroffen sind Organisationen, die Worker-Zugänge nie teilen, nur einen Worker betreiben oder das Deployment bewusst einem Plattformteam mit kontoweiter Verantwortung überlassen.

Der Schritt für Montag

Beginnen Sie mit der Berechtigungsrichtlinie für das CI-Deployment eines vorhandenen Kunden-Workers. Weisen Sie einem kontoeigenen Token die Rolle Editor zu, begrenzen Sie es auf diesen einen Worker, erfassen Sie alle Bindings und geerbten Durable Objects, die es beeinflussen kann, prüfen Sie direkte und über Gruppen vergebene Richtlinien und führen Sie dann ein Deployment ohne Änderung an Route oder Custom Domain aus.

Sobald dieser Lauf erfolgreich war, entfernen Sie die alten Zugangsdaten für alle Workers. Mit dieser einen Umstellung entsteht eine echte Grenze und zugleich ein Muster, das sich beim nächsten Kunden wiederholen lässt.

Wenn Sie weitere verständliche Hinweise zum Betrieb nach Plattformänderungen wünschen, abonnieren Sie den Newsletter.