Cloudflare unterteilte den Workers-Zugriff in Rollen und Geltungsbereiche statt in eine einzige große Berechtigungsliste

Als immer mehr Teams und autonome Coding-Agenten begannen, direkt auf Cloudflares Developer Platform bereitzustellen, erzwang das bestehende Berechtigungsmodell eine unangenehme Wahl: entweder weitreichende, kontoweite Rollen zu gewähren, die es einem Agenten erlauben, jeden Worker, jede Datenbank und jeden Bucket im Konto anzufassen, oder genügend einzelne Berechtigungen von Hand zusammenzustellen, um jeden Fall abzudecken – was mit wachsender Zahl von Ressourcen und Aktionen unüberschaubar wird.

Cloudflares Lösung bestand darin, den Zugriff nicht länger als eine flache Liste zu behandeln, sondern zwei unabhängige Dimensionen zu definieren. Vier Rollen – Metadata Read-Only, Content Read-Only, Editor und Admin – beschreiben Fähigkeitsstufen: von der Einsicht in Logs und Metriken, ohne den Code zu sehen, über das Lesen des Codes ohne Bearbeitung bis hin zur Bearbeitung ohne Löschung und zur vollständigen Kontrolle. Unabhängig davon kann jede Rolle auf einer von drei Ebenen angewendet werden: auf jede Ressource der Developer Platform, auf jede Ressource eines Produkts (alle Workers) oder auf eine einzelne benannte Ressource (einen bestimmten Worker).

Die beiden Achsen lassen sich unabhängig voneinander kombinieren. Eine CI/CD-Pipeline kann die Rolle Editor erhalten, beschränkt auf genau den einen Worker, den sie bereitstellt, sodass ein geleaktes Token diesen Worker aktualisieren, ihn aber nicht löschen oder eine andere Anwendung anfassen kann. Ein Debugging-Agent kann Metadata Read-Only erhalten, beschränkt auf einen Worker, sodass er Logs und Traces einsehen kann, ohne jemals den Quellcode zu lesen. Cloudflare entwarf dieselbe Struktur aus Rollen mal Geltungsbereichen so, dass sie sich später auf weitere Ressourcen der Developer Platform wie D1-Datenbanken und R2-Buckets ausweiten lässt, statt für jedes Produkt neue Berechtigungen zu erfinden.

Trennung von „was man tun kann“ (Rolle) und „wo man es tun kann“ (Geltungsbereich) als zwei unabhängige Achsen

Die Kombination von vier Rollen mit drei Geltungsbereichen ergibt zwölf präzise Zugriffsstufen aus einem kleinen, festen Vokabular, statt einer kombinatorischen Explosion einmaliger Berechtigungen pro Ressource.

Die Beschränkung auf eine einzelne Ressource (einen Worker) bedeutet, dass ein kompromittiertes oder falsch konfiguriertes Agenten-Token einen begrenzten Schadensradius hat – es kann keine andere Ressource im Konto sehen oder anfassen.

Dieselbe Rollen-/Geltungsbereichsstruktur wurde so gebaut, dass sie sich auf andere Produkte (D1, R2, KV) ausweiten lässt, ohne das Modell jedes Mal neu zu entwerfen.

Durable Objects erben den Zugriff von der Rolle ihres übergeordneten Workers, statt ein eigenes Berechtigungssystem zu benötigen, wodurch verhindert wird, dass das Modell weiter fragmentiert.

Wenn der Zugriffsbedarf mit mehr Agenten zunimmt, sollte man nicht mehr einzelne Berechtigungen hinzufügen, sondern die Zugriffskontrolle in zwei orthogonale Achsen aufteilen – Fähigkeit und Geltungsbereich –, die sich kombinieren lassen, statt sich zu vervielfachen.

Cloudflare fügte außerdem kontextbezogene 403-Fehlerantworten hinzu, die direkt auf die Dokumentation verlinken, in der beschrieben wird, welche Berechtigung fehlt, sodass ein Agent oder Entwickler, der auf eine Berechtigungsschranke stößt, sich selbst korrigieren kann, statt an einer generischen „Forbidden“-Antwort hängenzubleiben. Das Unternehmen erklärte, es plane, dasselbe Rollen-und-Geltungsbereich-Modell als Nächstes auf D1-Datenbanken, R2-Buckets und KV-Namespaces auszuweiten.