Opfield definiert 245 Berechtigungs-Scopes. Die folgenden Tabellen listen ihre genauen Namen und die Aktionen auf, die sie autorisieren. Vergeben Sie Berechtigungen über Gruppen oder die zusätzlichen Berechtigungen eines Benutzers; zur Einrichtung siehe Benutzer und Gruppen, Zugriff auf einen Ordner beschränken und API-Tokens, OAuth und MCP. In 2.11 umbenannte oder entfernte Scopes sind unter Außer Dienst gestellte Scope-Namen aufgeführt.
- Einschränkungen: Ressource bedeutet, dass der Scope einen Ressourcenqualifizierer unterstützt; Ordner bedeutet, dass er zusätzlich einen Ordnerqualifizierer unterstützt, und Ordner allein bedeutet, dass er nur einen Ordnerqualifizierer akzeptiert. App und Umgebung sind die App-Qualifizierer, die unter Apps beschrieben sind. — bedeutet, dass der Basis-Scope keinen Ressourcenqualifizierer hat. Bei Scopes der Git-Integration ist die Ressource ein Connector, eine GitLab-Gruppe oder ein GitLab-Projekt bzw. ein GitHub-Owner oder ein GitHub-Repository; siehe Einschränkungen der Git-Integration.
- Tokens: API bedeutet, dass der Scope an ein API-Token oder an OAuth für die Opfield API delegiert werden kann; MCP bedeutet, dass er an OAuth für die Opfield-MCP-Ressource delegiert werden kann. — bedeutet, dass keine der regulären Token-Familien ihn akzeptiert. Benutzerberechtigungen und Token-Berechtigungen sind nicht austauschbar.
- Eine Berechtigung aktiviert keine nicht verfügbare Produktfunktion, umgeht keine Lizenzanforderungen und gewährt keine Zugangsdaten oder Rechte beim externen Anbieter.
- Delegierter Zugriff ist durch die aktuellen wirksamen Berechtigungen des zugehörigen Benutzers begrenzt. Dass ein Scope für MCP zulässig ist, bedeutet nicht, dass ein entsprechendes Werkzeug existiert.
- API-Tokens und OAuth-Freigaben für die Opfield API oder MCP können jeden Scope tragen außer den Scopes nur für Benutzer für AI Workspace und AI-Sandboxes (
ai:workspace:use, feat:ai:configure, ai:skills:manage und ai:sandbox:*), mcp:use, admin:users:impersonate und integrations:gitlab:sandbox:clone. API-Tokens und OAuth-Autorisierungen selbst können nur aus einer interaktiven Sitzung heraus erstellt werden.
Eine Basisberechtigung wie proxy:view umfasst alle Routen. Eine qualifizierte Berechtigung wie proxy:view:<routeId> umfasst eine Route; proxy:view:folder/<folderId> umfasst die Routen im ausgewählten Ordner und seinen Unterordnern. Scopes für Routen, Pages, Speicher, Datenbanken und Docker sowie jeder Erstellungs-Scope akzeptieren außerdem node/<nodeId> für die Ressourcen auf einem Node.
Der Qualifizierer hängt vom Ressourcentyp ab. Docker-Container-Scopes verwenden <nodeId> für einen Node oder <nodeId>/<stableResourceId> für einen bestimmten Container oder ein bestimmtes Deployment. Qualifizierte Pages-Berechtigungen verwenden die Projekt-ID, einschließlich Operationen an seinen Deployments, Tags und Deploy-Tokens. Scopes der internen PKI verwenden die CA-ID. Wählen Sie das Ziel im Berechtigungseditor, statt eine ID eines anderen Ressourcentyps zu verwenden.
Opfield löst eine Ordnerberechtigung bei jeder Anfrage auf: Sie umfasst die Ressourcen, die sich jetzt im Ordner befinden, Ressourcen, die später darin erstellt oder dorthin verschoben werden, und nichts, was herausverschoben wurde. Bei Erstellungsberechtigungen wählt eine Ordnereinschränkung den Zielordner aus, nicht eine Ressource, die noch nicht erstellt wurde. Ordnerverwaltung und Ressourcenoperationen sind getrennte Berechtigungen: Die Verwaltung eines Ordners gewährt nicht selbst Zugriff auf jeden Eintrag darin, und das Verschieben eines Eintrags erfordert weiterhin dessen eigenen Bearbeitungs- oder Verwaltungs-Scope. Ein auf einen Ordner beschränkter Ordnerverwaltungs-Scope wie proxy:folders:manage:folder/<folderId> verwaltet die Unterordner dieses Ordners und was darin platziert ist, aber weder den Ordner selbst noch die oberste Ebene.
API-Tokens und OAuth-Freigaben werden in zwei Schritten aufgelöst: Zuerst werden ihre eigenen Ordner- und Node-Einschränkungen erweitert, und dann wird das Ergebnis durch den aktuellen Zugriff des Eigentümers begrenzt. Ein Token erreicht daher nie eine Ressource, die sein Eigentümer nicht erreichen kann, und eine Erstellungsberechtigung zählt beim Delegieren nie als Leseberechtigung. Fordert ein Token einen breiten Scope an, den der Eigentümer nur für einige Ressourcen besitzt, engt Opfield das Token auf diese Ressourcen ein.
Jeder Scope gehört zu einer Familie, die nach seinem längsten Präfix benannt ist, das einen Lese-Scope hat: proxy:* gehört zu proxy:view, docker:containers:* zu docker:containers:view, nodes:* zu nodes:details und docker:tasks:manage zu docker:tasks. Jeder Aktions-Scope schließt den Lese-Scope seiner Familie mit demselben Qualifizierer ein, einschließlich Lösch-Scopes. Zum Beispiel lässt proxy:edit:<routeId> den Inhaber diese Route sehen, docker:containers:manage:<nodeId> lässt den Inhaber jeden Container auf diesem Node sehen, und databases:query:read:<databaseId> zeigt diese Datenbank in der Datenbankliste, ohne globales databases:view zu gewähren.
Erstellungs-Scopes schließen überhaupt keine Ansicht ein: jeder Scope mit einem Bestandteil create, etwa proxy:create, docker:containers:create oder pki:templates:create, sowie docker:images:pull, ssl:cert:issue und pki:cert:issue. Das gilt unabhängig vom Qualifizierer – breit, ein Ordner oder ein Node –, sodass ein Benutzer mit nur proxy:create:folder/<folderId> Routen in diesem Ordner erstellen kann, die bereits darin liegenden Routen aber nicht sieht. Erstellungsdialoge zeigen weiterhin die Zielordner und Nodes, die ein solcher Benutzer wählen darf. Mit Auto-assign permissions for created resources, das standardmäßig aktiviert ist, behält der Ersteller die Ansicht jeder Ressource, die er erstellt; siehe Zugriff auf einen Ordner beschränken. Die einzige Ausnahme ist hosting:snapshots:create:<vmId>, das die Ansicht der Snapshots dieser VM behält.
Einige ausdrückliche Regeln vervollständigen das Bild:
- Zugriffsstufen:
storage:objects:admin schließt write ein, das read einschließt; databases:query:admin schließt write ein, das read einschließt; storage:credentials:reveal schließt storage:credentials:use ein.
ssl:cert:issue schließt ssl:cert:renew ein; pki:cert:export schließt pki:cert:deploy ein; docker:containers:secrets schließt docker:containers:environment ein; databases:edit schließt databases:bind ein; storage:iam schließt storage:bind ein.logs:read und logs:tokens:view (und damit logs:tokens:delete) schließen logs:environments:view ein; nodes:manage schließt nodes:config:view ein, das nodes:details einschließt; inference:models:manage schließt inference:providers:view ein; docker:availability:manage schließt docker:containers:view ein.- Scopes für Ordnerbäume (
*:folders:manage), nodes:backups:execute, proxy:maintenance:bypass und die älteren Scopes der internen Registry docker:registries:internal:pull und :push schließen keine Ansicht ein.
- Ein Lese-Scope schließt nie den Lese-Scope einer anderen Familie ein;
proxy:templates:view gewährt nicht proxy:view.
Jeder Ressourcentyp hat seinen eigenen Ordnerbaum. Ein Ordner unter Routes umfasst keine Container, auch wenn ein Docker-Ordner denselben Namen hat.
| Ressourcen |
Ordnereinschränkung |
Ordnerbaum verwaltet mit |
| Routen |
Ja |
proxy:folders:manage |
| Domains |
Ja |
domains:folders:manage |
| SSL-Zertifikate |
Ja |
ssl:cert:folders:manage |
| Pages-Projekte |
Ja |
pages:folders:manage |
| Nodes |
Ja |
nodes:folders:manage |
| Ingress-Gruppen |
Ja, im Node-Ordnerbaum; eine Gruppe liegt in einem Node-Ordner, und Node-Berechtigungen machen sie nicht sichtbar |
nodes:folders:manage |
| Docker-Container und Deployments |
Ja |
docker:folders:manage |
| Compose-Projekte, Docker-Netzwerke, Docker-Volumes, Docker-Images |
Ja; jeder Typ hat einen eigenen Baum |
docker:folders:manage |
| Datenbanken: externe Verbindungen und verwaltete Datenbanken |
Ja |
databases:folders:manage |
| Speicher: Speicherverbindungen und verwalteter Speicher |
Ja |
storage:folders:manage |
| Logging-Umgebungen; Logging-Schemas |
Ja |
logs:environments:folders:manage; logs:schemas:folders:manage |
| Benutzer; Berechtigungsgruppen |
Ja |
admin:users:folders:manage; admin:groups:folders:manage |
| Zertifizierungsstellen der internen PKI |
Ja; ein Ordner enthält ganze CA-Hierarchien, und eine Berechtigung umfasst jede Root-CA im Ordner und ihre Zwischen-CAs |
pki:ca:folders:manage |
| Zertifikate der internen PKI |
Ja |
pki:cert:folders:manage |
| nginx-Vorlagen |
Ja |
proxy:templates:folders:manage |
| Zertifikatsvorlagen |
Ordner organisieren nur die Liste; Scopes für Zertifikatsvorlagen werden nicht auf Ressourcen beschränkt |
pki:templates:folders:manage |
| Datenbank-Backups |
Über den Ordner der Datenbank |
— |
| Logging-Aufnahme-Tokens und Log-Suche |
Über den Ordner der Logging-Umgebung |
— |
| Workload Availability |
Über den Container- oder Compose-Ordner |
— |
Backup-Ausführende (nodes:backups:execute) |
Über den Ordner des Nodes |
— |
| Apps (sie verwenden stattdessen App- und Umgebungsqualifizierer), Access Lists, Docker-Registries, Docker-Tasks, Benachrichtigungen, Statusseite, SIEM, Integrationen, Hosting-Konten und -VMs, Inference, Opfield-Diagnose, Housekeeping, Lizenz und Einstellungen |
Nein |
— |
Scopes ohne Ordnerunterstützung sind global oder, wo der Katalog Ressource zeigt, auf eine Ressource beschränkt. Ordner für Hosting-Snapshots organisieren nur Snapshots; sie sind keine Zugriffsgrenze.
Scopes der Git-Integration können auf einen Connector und bei GitLab und GitHub auf Gruppen, Projekte, Owner oder Repositories darin beschränkt werden. Qualifizierer sind stabile IDs des Anbieters, niemals Namen oder Pfade, sodass das Umbenennen oder Verschieben einer Gruppe oder eines Repositorys eine Berechtigung nie ändert.
| Qualifizierer |
Umfasst |
<scope>:<connectorId> |
Jedes Repository dieses Connectors |
<scope>:<connectorId>/group/<groupId> |
GitLab: die Gruppe, ihre Untergruppen und jedes Projekt darunter. Opfield liest die übergeordneten Gruppen eines Projekts aus GitLab und speichert sie einige Minuten zwischen, sodass ein verschobenes Projekt seiner neuen Gruppe folgt |
<scope>:<connectorId>/project/<projectId> |
GitLab: dieses Projekt |
<scope>:<connectorId>/owner/<ownerId> |
GitHub: jedes Repository dieser Organisation oder dieses Benutzers |
<scope>:<connectorId>/repo/<repoId> |
GitHub: dieses Repository |
- Welche Scopes:
view, use, repo:read und repo:write von GitLab und GitHub sowie integrations:gitlab:sandbox:clone akzeptieren jeden Qualifizierer ihres Anbieters. Generische Git-Scopes akzeptieren nur den Connector. integrations:<provider>:manage ist breit oder auf einen Connector beschränkt: Die Verwaltung einer Verbindung – ihrer Einstellungen, Tokens, Repository-Allowlist, Synchronisation, ihres Tests und ihrer Löschung – erfordert ihn auf diesem Connector, und das Erstellen eines Connectors erfordert ihn breit. Eine Berechtigung auf eine Gruppe, einen Owner, ein Projekt oder ein Repository erlaubt nie die Verwaltung eines Connectors.
- Abgleich: Eine Operation an einem Repository wird durch den breiten Scope, den Connector-Qualifizierer, jede Gruppe bzw. jeden Owner, die bzw. der das Repository enthält, oder das genaue Projekt bzw. Repository erlaubt. Der implizierte Lesezugriff funktioniert pro Qualifizierer:
integrations:gitlab:repo:write:<connectorId>/project/42 zeigt auch Projekt 42. Ordnerqualifizierer gelten nicht für Integrationen.
- Was geprüft wird: Jede Repository-Operation prüft das Repository – Dateien, Trees, Branches, Commits, CI-Pipelines, Job-Logs und -Variablen, Webhooks, Deploy-Tokens, Registry-Einstellungen, Sandbox-Klone sowie Docker- und Pages-Build-Quellen –, in der REST API, im AI Workspace und in MCP gleichermaßen.
- Zugangsdaten: Opfield verwendet die eigenen Zugangsdaten des Connectors, wenn
integrations:<provider>:use das Repository auf dieselbe Weise abdeckt, und andernfalls die persönlichen Zugangsdaten des Aufrufers. Ohne beides werden Benutzer von AI Workspace aufgefordert, persönliche Zugangsdaten zu autorisieren, und andere Aufrufer erhalten 403 mit Nennung von integrations:<provider>:use und dem Repository.
- Verborgene Projekte: Ein GitLab-Projekt außerhalb der Berechtigung des Aufrufers antwortet genau wie ein Projekt, das nicht synchronisiert ist (
404, kein Pfad). Schreibvorgänge, Secrets, Sandbox-Klone und die Entscheidung über die Zugangsdaten lesen die Gruppenabstammung und die Repository-Zuständigkeit frisch beim Anbieter; Lesevorgänge können einen bis zu fünf Minuten alten zwischengespeicherten Wert verwenden, und die GitHub-Zuständigkeit wird nach Repository-ID zwischengespeichert, nie nach Pfad. Änderungsereignisse von Connectoren über den WebSocket erreichen nur Aufrufer, die diesen Connector sehen dürfen.
- Listen: Connector-Listen enthalten die Connectoren, auf denen der Aufrufer einen beliebigen Git-Scope besitzt; ein Connector, der nur über engere Berechtigungen sichtbar ist, wird ohne seine Allowlist zurückgegeben. Projekt- und Repository-Listen enthalten nur, was die Berechtigungen abdecken.
- Build-Quellen: Das Konfigurieren einer Docker- oder Pages-Build-Quelle erfordert
integrations:<provider>:use auf dem Repository, mit einem beliebigen Qualifizierer, der es abdeckt, neben den eigenen Berechtigungen des Workloads. repo:read, breites view und persönliche Zugangsdaten sind nicht erforderlich, weil Builds die Zugangsdaten des Connectors verwenden. Die Quellauswahl listet die Connectoren und Repositories auf, die die Git-Scopes des Aufrufers abdecken, da use view einschließt. Ein manueller Build prüft das use des Aufrufers auf dem gespeicherten Repository erneut. Vor 2.11 gespeicherte Quellen bauen wie bisher automatisch weiter; eine nach dem Update erstellte oder erneut gespeicherte Quelle baut über Polling und Webhooks nur, solange das Konto, das sie gespeichert hat, noch use auf dem Repository besitzt, und erfasst andernfalls einen abgebrochenen Build Build paused: <user> no longer has use on <repo>, bis dieser Zugriff zurückkehrt oder jemand mit use die Quelle erneut speichert.
- Tokens und OAuth-Freigaben: Ein delegierter Git-Scope wird pro Qualifizierer durch den Eigentümer begrenzt. Ein breiterer Token-Scope wird auf die Qualifizierer des Eigentümers eingeengt, und ein Token-Scope, der auf eine Gruppe, einen Owner, ein Projekt oder ein Repository beschränkt ist, bleibt erhalten, wenn der Eigentümer denselben Scope oder einen, der ihn einschließt, irgendwo auf diesem Connector besitzt. Da die Enthaltenseins-Beziehung Anbieterdaten sind, erfordert jede Repository-Operation eines Token- oder OAuth-Aufrufers, dass sowohl das Token als auch die aktuellen Scopes des Eigentümers das Repository abdecken: Ein auf Projekt P beschränktes Token funktioniert, solange sein Eigentümer die Gruppe besitzt, die P enthält, und ein auf Gruppe G beschränktes Token, dessen Eigentümer nur Projekt P besitzt, erreicht nur P. Solche engen Token-Scopes zählen nie, wenn das Token Benutzern oder Gruppen Berechtigungen gewährt.
Der Gruppeneditor, die zusätzlichen Berechtigungen von Benutzern, das Formular für API-Tokens sowie die OAuth- und MCP-Zustimmung bieten diese Einschränkungen unter jedem Connector an, mit einer Suchauswahl für Gruppen und Projekte bzw. Owner und Repositories. Die Auswahl liest GET /api/integrations/{provider}/{connectorId}/scope-targets?search=&limit=50, wobei provider gitlab oder github ist, und zeigt die Bezeichnungen gespeicherter Qualifizierer über GET /api/integrations/{provider}/{connectorId}/scope-targets/resolve?ids=group/123,project/456. Beide Endpunkte erfordern integrations:<provider>:view auf dem Connector oder auf etwas darin und liefern nur die Ziele, die der Aufrufer sehen darf und die die Allowlist des Connectors enthält. Sie teilen sich ein Limit von 60 Anfragen pro Minute und Konto, danach liefern sie 429 SCOPE_TARGET_RATE_LIMITED mit Retry-After, und eine Anfrage führt höchstens 60 nicht zwischengespeicherte Abfragen beim Anbieter aus; weitere Ziele behalten ihre rohen IDs. Ein Ziel, das nicht mehr existiert, wird als missing markiert und als Unavailable angezeigt; ein gespeicherter Qualifizierer, den der Aufrufer nicht sehen kann, behält seine rohe ID als Bezeichnung.
Opfield 2.11 hat die unten aufgeführten Scopes umbenannt, zusammengeführt oder entfernt. Das Update hat jede gespeicherte Berechtigung umgeschrieben – Gruppen, zusätzliche Berechtigungen von Benutzern, API-Tokens und OAuth-Freigaben – und jeden Qualifizierer beibehalten, sodass aus nodes:config:edit:<nodeId> nodes:manage:<nodeId> wurde. Damit niemand Zugriff verlor, erhielten Inhaber von pki:ca:create:root zusätzlich pki:ca:edit und pki:ca:export; Inhaber von integrations:github:view oder integrations:git:view erhielten :repo:read; Inhaber von integrations:github:manage oder integrations:git:manage erhielten :repo:read und :repo:write; und Inhaber von breitem oder Node-bezogenem docker:volumes:create (zum Beispiel docker:volumes:create:<nodeId>) erhielten docker:volumes:edit mit demselben Qualifizierer; ordnerbezogene Erstellungsberechtigungen und reine Löschberechtigungen nicht.
Für zwei Releases akzeptiert Opfield die alten Namen bei der Eingabe weiterhin und schreibt sie auf dieselbe Weise um: den OAuth-Parameter scope, das Erstellen und Aktualisieren von API-Tokens, das Erstellen und Aktualisieren von Berechtigungsgruppen, zusätzliche Berechtigungen von Benutzern und Bearbeitungen von OAuth-Autorisierungen. Eine Anfrage, deren Scopes alle entfernt wurden, wird abgelehnt. Neue API-Tokens und OAuth-Anfragen erhalten außerdem die oben genannten Ergänzungen, sofern der Anfragende sie besitzt – zum Beispiel erhält ein mit integrations:github:manage angefordertes Token auch repo:read –, und der Zustimmungsbildschirm zeigt sie an, damit sie abgewählt werden können. Scopes, die eine manuelle Freigabe erfordern, etwa repo:write oder pki:ca:export, werden bei der Eingabe nie hinzugefügt. Berechtigungsprüfungen verwenden nur die aktuellen Namen; aktualisieren Sie daher Skripte, OAuth-Clients und Infrastructure-as-Code-Definitionen, bevor die Aliase entfernt werden.
| Außer Dienst gestellt |
Ersatz |
ssl:cert:revoke, ssl:cert:export |
Entfernt; sie wurden nie durchgesetzt |
notifications:view |
notifications:alerts:view und notifications:webhooks:view |
notifications:manage |
notifications:alerts:manage und notifications:webhooks:manage |
notifications:alerts:create, :edit, :delete |
notifications:alerts:manage |
notifications:webhooks:create, :edit, :delete |
notifications:webhooks:manage |
notifications:deliveries:view |
notifications:webhooks:view |
logs:manage |
Jeder logs:*-Scope |
docker:containers:config |
Entfernt. Duplizieren und Neuerstellen erfordern docker:containers:environment und docker:containers:secrets; die Dienstadresse eines Docker Nodes erfordert nodes:manage |
nodes:config:edit |
nodes:manage |
pki:ca:view:root, pki:ca:view:intermediate |
pki:ca:view |
integrations:gitlab:sync, integrations:github:sync, integrations:git:sync |
integrations:<provider>:manage |
integrations:gitlab:system, integrations:github:system, integrations:git:system |
integrations:<provider>:use |
integrations:gitlab:projects:view |
integrations:gitlab:view |
integrations:gitlab:ci:view, :variables:view |
integrations:gitlab:repo:read |
integrations:gitlab:ci:edit, :variables:edit, :variables:delete, :webhooks:manage, :registry:manage |
integrations:gitlab:repo:write |
proxy:raw:toggle |
Entfernt; das Umschalten des Raw-Modus erfordert proxy:raw:write |
proxy:advanced:bypass, proxy:raw:bypass |
proxy:unrestricted |
proxy:templates:create, :edit, :delete |
proxy:templates:manage |
docker:containers:folders:manage |
docker:folders:manage |
Manche Ersatz-Scopes sind breiter als der Scope, den sie ersetzen; prüfen Sie daher Gruppen, Benutzerberechtigungen, API-Tokens und OAuth-Freigaben, die sie besaßen: integrations:gitlab:repo:write committet außerdem Repository-Dateien und ändert CI-Konfiguration, Variablen, Webhooks und Registry-Einstellungen; integrations:gitlab:repo:read liest außerdem Repository-Dateien; die Berechtigung manage eines Connectors umfasst seine Einstellungen, Tokens, Allowlist, seinen Test und seine Löschung; nodes:manage installiert außerdem die Secure Runtime, ändert Dienstadressen und steuert gehostete VMs; proxy:unrestricted hebt sowohl die Einschränkungen der erweiterten als auch der rohen Konfiguration auf; und notifications:webhooks:manage legt außerdem Webhook-URLs, -Header und Zustellungs-Nutzdaten offen. Aus integrations:gitlab:variables:view wurde integrations:gitlab:repo:read, das Variablenschlüssel liest, aber nicht ihre Werte. Siehe Update von 2.10.
In 2.12.1 wurden settings:gateway:view und settings:gateway:edit zu settings:opfield:view und settings:opfield:edit. Das Update hat jede gespeicherte Berechtigung umgeschrieben, einschließlich API-Tokens und OAuth-Freigaben; Skripte und OAuth-Clients müssen die neuen Namen anfordern.
Weitere Berechtigungsänderungen in 2.11:
- Neue Scopes:
pki:ca:edit (CA-URLs, maximale Gültigkeit und OCSP-Responder) und pki:ca:export (Export des privaten Schlüssels einer CA), beide auf eine CA beschränkbar; docker:volumes:edit (Volumes umbenennen, neu beschriften, in der Größe ändern und übernehmen); integrations:github:repo:read, :repo:write, integrations:git:repo:read und :repo:write.
- Git-Anbieter teilen dieselben Verben:
view listet Connectoren auf, manage konfiguriert, testet und synchronisiert sie, use verwendet die eigenen Zugangsdaten des Connectors, und repo:read und repo:write lesen bzw. ändern Repository-Inhalte. Jeder kann auf einen Connector und bei GitLab und GitHub auf Gruppen, Projekte, Owner oder Repositories beschränkt werden; siehe Einschränkungen der Git-Integration. Das Auflisten und Lesen der synchronisierten Projekte von GitLab erfordert integrations:gitlab:view. GitLab-repo:read umfasst Repository-Dateien, CI-Pipelines und Job-Logs sowie Schlüssel von CI/CD-Variablen, niemals Werte; das Ändern von Variablen erfordert repo:write. Das Lesen von Werten der GitHub-Actions-Variablen erfordert integrations:github:repo:write. Die integrierten Gruppen viewer und operator erhalten nur integrations:gitlab:view.
- Vorlagen: Das Schreiben von Inhalten von nginx-Vorlagen erfordert
proxy:templates:manage und nicht mehr proxy:raw:write. Die integrierte Gruppe operator behält nur proxy:templates:view, weil Vorlageninhalte rohe nginx-Konfiguration sind.
- Ordnerberechtigungen werden jetzt für
logs:tokens:* (über den Ordner der Logging-Umgebung) und docker:availability:manage (über den Container- oder Compose-Ordner) aufgelöst. Zertifizierungsstellen, Zertifikate der internen PKI und nginx-Vorlagen können in Ordnern organisiert und pro Ordner vergeben werden; siehe Ordnerunterstützung nach Ressourcentyp.
- Implizierter Lesezugriff: Jede Aktionsberechtigung außer Erstellen schließt die Leseberechtigung ihrer Familie mit demselben Qualifizierer ein, sodass eine reine Löschberechtigung diese Ressourcen jetzt auch auflistet und anzeigt; siehe Implizierter Lesezugriff.
- Neue Berechtigungen für neue Funktionen:
diagnostics:view und diagnostics:logs, databases:backups:*, nodes:backups:execute und die storage:*-Scopes. Integrierte Gruppen haben sie erhalten; benutzerdefinierte Berechtigungsgruppen nicht, vergeben Sie sie daher bei Bedarf.
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
pki:ca:view |
Root- und Zwischenzertifizierungsstellen ansehen |
Ressource, Ordner |
API, MCP |
pki:ca:create:root |
Neue Root-Zertifizierungsstellen erstellen |
— |
API, MCP |
pki:ca:create:intermediate |
Zwischen-CAs unter einer Root erstellen |
Ressource |
API, MCP |
pki:ca:edit |
CA-URLs, maximale Gültigkeit und OCSP-Responder bearbeiten |
Ressource, Ordner |
API, MCP |
pki:ca:export |
Eine Zertifizierungsstelle samt privatem Schlüssel exportieren |
Ressource, Ordner |
API, MCP |
pki:ca:folders:manage |
CA-Ordner verwalten. Nur Root-CAs werden verschoben, und ihre Zwischen-CAs folgen; das Verschieben einer Root-CA erfordert außerdem pki:ca:edit auf ihr und auf dem Ziel |
Ordner |
API, MCP |
pki:ca:revoke:root |
Root-Zertifizierungsstellen widerrufen |
— |
API, MCP |
pki:ca:revoke:intermediate |
Zwischenzertifizierungsstellen widerrufen |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
pki:cert:view |
Ausgestellte Zertifikate ansehen |
Ressource, Ordner |
API, MCP |
pki:cert:issue |
Neue Zertifikate ausstellen |
Ressource |
API, MCP |
pki:cert:revoke |
Ausgestellte Zertifikate widerrufen |
Ressource, Ordner |
API, MCP |
pki:cert:export |
Zertifikate und Schlüssel exportieren |
Ressource, Ordner |
API, MCP |
pki:cert:deploy |
TLS-Serverzertifikate für Routen anhängen oder verknüpfen; nginx verwendet den Schlüssel, der Aufrufer sieht ihn nie. Das Verknüpfen in den SSL-Speicher erfordert außerdem ssl:cert:issue |
Ressource, Ordner |
API, MCP |
pki:cert:folders:manage |
Ordner für PKI-Zertifikate verwalten; das Verschieben eines Zertifikats erfordert außerdem pki:cert:issue auf seiner ausstellenden CA |
Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
pki:templates:view |
Zertifikatsvorlagen ansehen |
— |
API, MCP |
pki:templates:create |
Zertifikatsvorlagen erstellen |
— |
API, MCP |
pki:templates:edit |
Zertifikatsvorlagen bearbeiten |
— |
API, MCP |
pki:templates:delete |
Zertifikatsvorlagen löschen |
— |
API, MCP |
pki:templates:folders:manage |
Ordner für Zertifikatsvorlagen verwalten; das Verschieben einer benutzerdefinierten Vorlage erfordert außerdem pki:templates:edit, und integrierte Vorlagen werden nie verschoben |
Ordner |
API, MCP |
App-Scopes akzeptieren zwei Qualifizierer: <appId> für eine App und env/<envId> für eine ihrer Umgebungen. Die Zugriffszeile In an app environment im Berechtigungseditor setzt sie zusammen mit Ordnerberechtigungen für die Ressourcen dieser Umgebung; siehe Berechtigungen für Apps.
Ohne apps:view ist eine App für einen Benutzer dennoch sichtbar, der eine ihrer Ressourcen über eigene Berechtigungen sehen kann, einschließlich einer Berechtigung auf dem Ordner der Umgebung oder der App. Dieser Benutzer sieht nur die Umgebungen, die solche Ressourcen enthalten, und nur diese Ressourcen, und Overview und Activity umfassen nur sie. Einstellungen, erlaubte Nodes, Wartung, Variablen, Übernahme und jede Aktion erfordern weiterhin die App-Scopes. Siehe Wer eine App sieht.
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
apps:view |
Die gesamte App ansehen: alle ihre Umgebungen, Übersicht und Aktivität; Ressourcen benötigen weiterhin ihre eigenen Lese-Scopes. Ohne diesen Scope ist eine App nur über die Ressourcen sichtbar, die der Benutzer sehen kann |
App, Umgebung |
API, MCP |
apps:create |
Apps erstellen |
— |
API, MCP |
apps:edit |
Die App umbenennen, Umgebungen hinzufügen, umbenennen und löschen und die Production-Kennzeichnung verschieben |
App |
API, MCP |
apps:delete |
Die App löschen; ihre Ressourcen laufen weiter und verlassen die App |
App |
API, MCP |
apps:env:manage |
Variablen und Secrets der Umgebung, erlaubte Nodes, Wartung der Umgebung und Zugangscodes sowie das Hinein- und Herausverschieben von Ressourcen zusammen mit dem eigenen Bearbeitungs-Scope der Ressource |
App, Umgebung |
API, MCP |
apps:promote |
In die Umgebung übernehmen |
App, Umgebung |
API, MCP |
apps:operate |
Herunterfahren, starten und isolieren; die Wartung für die gesamte App erfordert ihn auf der App |
App, Umgebung |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
domains:view |
Verwaltete Domains ansehen |
Ressource, Ordner |
API, MCP |
domains:create |
Verwaltete Domains erstellen |
Ressource, Ordner |
API, MCP |
domains:edit |
Verwaltete Domains bearbeiten |
Ressource, Ordner |
API, MCP |
domains:delete |
Verwaltete Domains löschen |
Ressource, Ordner |
API, MCP |
domains:folders:manage |
Verwaltete Domains in Ordnern organisieren |
Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
proxy:view |
Ingress-Routen ansehen und durchsuchen |
Ressource, Ordner |
API, MCP |
proxy:create |
Neue Ingress-Routen erstellen |
Ressource, Ordner |
API, MCP |
proxy:edit |
Konfiguration von Ingress-Routen bearbeiten |
Ressource, Ordner |
API, MCP |
proxy:delete |
Ingress-Routen löschen |
Ressource, Ordner |
API, MCP |
proxy:raw:read |
Rohe nginx-Konfiguration ansehen |
Ressource, Ordner |
API, MCP |
proxy:raw:write |
Rohe nginx-Konfiguration bearbeiten und Routen zwischen verwaltetem und rohem Modus umschalten |
Ressource, Ordner |
API, MCP |
proxy:advanced |
Erweiterte Proxy-Konfiguration verwenden |
Ressource, Ordner |
API, MCP |
proxy:unrestricted |
Erweiterte Snippets und rohe nginx-Konfiguration ohne Einschränkungen für gefährliche Direktiven speichern |
Ressource, Ordner |
API, MCP |
proxy:maintenance:bypass |
Vorübergehende Zugangscodes für Routen in Wartung erstellen |
Ressource, Ordner |
API, MCP |
proxy:folders:manage |
Routenordner erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
pages:view |
Pages-Projekte, Deployments, Tags, Vorschauen und Nutzung ansehen |
Ressource, Ordner |
API, MCP |
pages:create |
Statische Pages-Projekte erstellen |
Ressource, Ordner |
API, MCP |
pages:edit |
Pages-Projekte umbenennen und ihre Aufbewahrungs- und Kontingenteinstellungen bearbeiten |
Ressource, Ordner |
API, MCP |
pages:delete |
Geeignete Pages-Projekte löschen |
Ressource, Ordner |
API, MCP |
pages:deploy |
Statische Deployments erstellen und hochladen |
Ressource, Ordner |
API, MCP |
pages:deployments:manage |
Geeignete Deployments anheften, lösen, bereinigen und löschen |
Ressource, Ordner |
API, MCP |
pages:tags:manage |
Tags von Pages-Projekten erstellen, verschieben und löschen |
Ressource, Ordner |
API, MCP |
pages:tokens:manage |
Deploy-Zugangsdaten von Projekten erstellen, einschränken und widerrufen |
Ressource, Ordner |
API, MCP |
pages:folders:manage |
Ordner für Pages-Projekte erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
pages:settings:view |
Wildcard-Profil und Speicherstandards ansehen |
— |
API, MCP |
pages:settings:edit |
Das Wildcard-Profil von Pages und Speicherstandards konfigurieren und migrieren |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
proxy:templates:view |
nginx-Vorlagen ansehen |
Ressource, Ordner |
API, MCP |
proxy:templates:manage |
nginx-Vorlagen erstellen, bearbeiten und löschen, einschließlich Vorlageninhalten; mit einem Ordnerqualifizierer außerdem Vorlagen in diesem Ordner erstellen |
Ressource, Ordner |
API, MCP |
proxy:templates:folders:manage |
Ordner für nginx-Vorlagen verwalten; das Verschieben einer benutzerdefinierten Vorlage erfordert außerdem proxy:templates:manage auf ihr und auf dem Ziel, und integrierte Vorlagen werden nie verschoben |
Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
ssl:cert:view |
SSL-Zertifikate ansehen |
Ressource, Ordner |
API, MCP |
ssl:cert:issue |
ACME-Zertifikate bereitstellen oder SSL-Zertifikate hochladen; verlängert sie außerdem |
Ressource, Ordner |
API, MCP |
ssl:cert:renew |
Bestehende Zertifikate verlängern, ihre DNS-Prüfung abschließen und die automatische Verlängerung festlegen |
Ressource, Ordner |
API, MCP |
ssl:cert:folders:manage |
SSL-Zertifikate in Ordnern organisieren |
Ordner |
API, MCP |
ssl:cert:delete |
SSL-Zertifikate löschen |
Ressource, Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
acl:view |
Access Lists ansehen |
Ressource |
API, MCP |
acl:create |
Access Lists erstellen |
— |
API, MCP |
acl:edit |
Access Lists bearbeiten |
Ressource |
API, MCP |
acl:delete |
Access Lists löschen |
Ressource |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
nodes:details |
Verwaltete Nodes ansehen |
Ressource, Ordner |
API, MCP |
nodes:create |
Neue Nodes registrieren |
Ressource, Ordner |
API, MCP |
nodes:rename |
Nodes umbenennen |
Ressource, Ordner |
API, MCP |
nodes:delete |
Nodes entfernen |
Ressource, Ordner |
API, MCP |
nodes:config:view |
nginx-Konfiguration von Nodes ansehen |
Ressource, Ordner |
API, MCP |
nodes:manage |
nginx-Konfiguration von Nodes bearbeiten, die sichere Docker-Laufzeit installieren, Dienstadressen ändern und gehostete VMs steuern |
Ressource, Ordner |
API, MCP |
nodes:logs |
Daemon- und nginx-Logs von Nodes ansehen |
Ressource, Ordner |
API, MCP |
nodes:console |
Interaktive Shell auf Nodes öffnen |
Ressource, Ordner |
API, MCP |
nodes:files:read |
Dateien auf Nodes durchsuchen, öffnen, kopieren und herunterladen |
Ressource, Ordner |
API, MCP |
nodes:files:write |
Dateien auf Nodes erstellen, bearbeiten, hochladen, verschieben und löschen |
Ressource, Ordner |
API, MCP |
nodes:lock |
Neue Proxy-Hosts oder Container auf ausgewählten Nodes verhindern |
Ressource, Ordner |
API, MCP |
nodes:folders:manage |
Node-Ordner erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
ingress:groups:view |
Ingress-Gruppen, ihre Mitglieder und die Auslieferung pro Mitglied ansehen; Routen und Domains darauf platzieren |
Ordner |
API, MCP |
ingress:groups:manage |
Ingress-Gruppen erstellen, bearbeiten und löschen und ihre Mitglieder ändern; das Hinzufügen eines Nodes erfordert außerdem nodes:manage darauf |
Ordner |
API, MCP |
Scopes für Ingress-Gruppen akzeptieren nur einen Qualifizierer für einen Node-Ordner. Node-Berechtigungen machen Ingress-Gruppen nicht sichtbar.
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
admin:users |
Benutzer erstellen, bearbeiten und löschen |
Ressource, Ordner |
API, MCP |
admin:users:impersonate |
Vorübergehend als ein anderer aktiver Benutzer handeln |
Ressource, Ordner |
— |
admin:users:folders:manage |
Benutzerordner erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
admin:groups |
Berechtigungsgruppen erstellen, bearbeiten und löschen |
Ressource, Ordner |
API, MCP |
admin:groups:folders:manage |
Ordner für Berechtigungsgruppen erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
admin:audit |
Das Audit-Log ansehen |
— |
API, MCP |
audit:siem:view |
SIEM-Ziele und den Zustellverlauf des Audits ansehen |
— |
API, MCP |
audit:siem:manage |
SIEM-Ziele konfigurieren und Audit-Zustellungen steuern |
— |
API, MCP |
admin:system |
Administration auf Systemebene (geschützt) |
— |
API, MCP |
admin:details:certificates |
Interne System-PKI und SSL-Zertifikate schreibgeschützt ansehen |
— |
API, MCP |
admin:update |
Nach Updates suchen und sie anwenden |
— |
API, MCP |
admin:alerts |
Alarme ansehen und verwalten |
— |
API, MCP |
diagnostics:view |
Den eigenen Zustand von Opfield und seinen 48-stündigen Minutenverlauf lesen: CPU, Arbeitsspeicher und Festplatte des Hosts, den Backend-Prozess, sein PostgreSQL und Redis, die Stack-Container, Hintergrundjobs und API-Latenz. Im Besitz der integrierten Admin-Gruppen |
— |
API, MCP |
diagnostics:logs |
Die Logs der eigenen Container von Opfield (app, PostgreSQL, Redis, Relay, Registry) und des letzten Update-Laufs lesen; schließt diagnostics:view ein. Im Besitz der integrierten Admin-Gruppen |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
settings:opfield:view |
Einstellungen zur Anmeldebereitstellung und zur externen Control Plane ansehen |
— |
API, MCP |
settings:opfield:edit |
Einstellungen zur Anmeldebereitstellung und zur externen Control Plane bearbeiten |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
integrations:gitlab:view |
Konfigurierte GitLab-Connectoren, Synchronisationsstatus und synchronisierte Projekte ansehen |
Ressource |
API, MCP |
integrations:gitlab:manage |
GitLab-Connectoren erstellen, bearbeiten, rotieren, synchronisieren und löschen |
Ressource |
API, MCP |
integrations:gitlab:use |
Die Zugangsdaten des Connectors für ansonsten erlaubte GitLab-Operationen verwenden und Docker- und Pages-Build-Quellen aus einem Projekt konfigurieren |
Ressource |
API, MCP |
integrations:gitlab:repo:read |
Repository-Dateien, CI-Pipelines und Job-Logs sowie Schlüssel von CI/CD-Variablen (niemals Werte) über GitLab-Connectoren lesen |
Ressource |
API, MCP |
integrations:gitlab:repo:write |
Repository-Dateien, CI-Konfiguration, CI/CD-Variablen, Webhooks und Registry-Einträge über GitLab-Connectoren ändern |
Ressource |
API, MCP |
integrations:gitlab:sandbox:clone |
Erlaubte GitLab-Repositories in AI-Sandboxes klonen |
Ressource |
— |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
integrations:github:view |
Konfigurierte GitHub-Token-Connectoren ansehen |
Ressource |
API, MCP |
integrations:github:manage |
GitHub-Token-Connectoren erstellen, bearbeiten, rotieren, synchronisieren und löschen |
Ressource |
API, MCP |
integrations:github:use |
Die Zugangsdaten des Connectors statt einer persönlichen GitHub-Autorisierung verwenden und Docker- und Pages-Build-Quellen aus einem Repository konfigurieren |
Ressource |
API, MCP |
integrations:github:repo:read |
Repositories auflisten und Dateien über GitHub-Connectoren lesen (keine Werte von Actions-Variablen) |
Ressource |
API, MCP |
integrations:github:repo:write |
Repository-Dateien und Secrets ändern sowie Actions-Variablen über GitHub-Connectoren lesen oder ändern |
Ressource |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
integrations:git:view |
Konfigurierte generische Git-Connectoren ansehen |
Ressource |
API, MCP |
integrations:git:manage |
Generische Git-Connectoren erstellen, bearbeiten, rotieren, synchronisieren und löschen |
Ressource |
API, MCP |
integrations:git:use |
Die Zugangsdaten des Connectors statt einer persönlichen Git-Autorisierung verwenden und Docker- und Pages-Build-Quellen aus einem Repository konfigurieren |
Ressource |
API, MCP |
integrations:git:repo:read |
Repositories auflisten und Dateien über generische Git-Connectoren lesen |
Ressource |
API, MCP |
integrations:git:repo:write |
Repository-Dateien über generische Git-Connectoren ändern |
Ressource |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
integrations:ssh:view |
Konfigurierte externe SSH-Server ansehen |
— |
API, MCP |
integrations:ssh:manage |
Externe SSH-Server und Jump-Hosts hinzufügen und konfigurieren |
— |
API, MCP |
integrations:ssh:use |
Freigegebene Befehle auf konfigurierten externen SSH-Servern ausführen |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
integrations:cloudflare:view |
Konfigurierte Cloudflare-Connectoren und Synchronisationsstatus ansehen |
— |
API, MCP |
integrations:cloudflare:sync |
Cloudflare-Zonen und Token-Fähigkeiten mit den Zugangsdaten des Connectors aktualisieren |
— |
API, MCP |
integrations:cloudflare:manage |
Cloudflare-Connectoren erstellen, bearbeiten, testen, synchronisieren, rotieren und löschen |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
integrations:hosting:view |
Hosting-Konten und Verbindungsstatus ansehen |
Ressource |
API, MCP |
integrations:hosting:manage |
Hosting-Konten verbinden, konfigurieren und synchronisieren |
Ressource |
API, MCP |
hosting:resources:view |
Inventar des Anbieters und zugehörige Opfield-Nodes ansehen |
Ressource |
API, MCP |
hosting:resources:create |
VMs beim Anbieter bestellen und Opfield-Rollen installieren; kann Kosten verursachen |
Ressource |
API, MCP |
hosting:resources:power |
VMs starten, herunterfahren und neu starten; alle gehosteten Rollen sind betroffen |
Ressource |
API, MCP |
hosting:resources:resize |
VM-Ressourcen ändern; kann die Kosten beim Anbieter ändern |
Ressource |
API, MCP |
hosting:snapshots:view |
Snapshots und Snapshot-Ordner des Anbieters ansehen, ohne die VM zu ändern |
Ressource |
API, MCP |
hosting:snapshots:create |
Snapshots beim Anbieter erstellen; Speicher kann Kosten verursachen |
Ressource |
API, MCP |
hosting:snapshots:delete |
Snapshots beim Anbieter dauerhaft löschen |
Ressource |
API, MCP |
hosting:snapshots:restore |
Aktuelle VM-Daten durch einen Snapshot ersetzen |
Ressource |
API, MCP |
hosting:snapshots:folders:manage |
Snapshot-Ordner erstellen und Snapshots zwischen Ordnern verschieben |
Ressource |
API, MCP |
hosting:resources:delete |
VM-Daten beim Anbieter vernichten oder eine HOSTKEY-Miete kündigen |
Ressource |
API, MCP |
hosting:resources:recover |
Opfield-Daemons neu starten oder eine fehlgeschlagene Installation ausdrücklich wiederholen |
Ressource |
API, MCP |
hosting:billing:view |
Kontostand, Kosten, Rechnungen und Transaktionen ansehen |
Ressource |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
housekeeping:view |
Housekeeping-Konfiguration, Statistiken und Laufverlauf ansehen |
— |
API, MCP |
housekeeping:run |
Housekeeping-Aufgaben manuell ausführen |
— |
API, MCP |
housekeeping:configure |
Housekeeping-Konfiguration und Zeitplan bearbeiten |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
license:view |
Lizenzstatus und Details zum Leistungsumfang von Opfield ansehen |
— |
API, MCP |
license:manage |
Die Opfield-Lizenz aktivieren, aktualisieren oder entfernen |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
ai:workspace:use |
Die Oberfläche von AI Workspace und den eingebetteten Assistenten verwenden |
— |
— |
feat:ai:use |
Opfield Inference verwenden und die persönliche Inference-Nutzung ansehen |
— |
API, MCP |
feat:ai:configure |
KI-Einstellungen und -Anbieter konfigurieren |
— |
— |
ai:skills:manage |
Skills von AI Workspace erstellen, bearbeiten, aktivieren, deaktivieren und löschen |
— |
— |
ai:sandbox:use |
Begrenzte Jobs in AI-Sandboxes ausführen |
— |
— |
ai:sandbox:tier:medium |
Jobs in AI-Sandboxes mit mittleren Ressourcenlimits ausführen |
— |
— |
ai:sandbox:tier:high |
Jobs in AI-Sandboxes mit hohen Ressourcenlimits ausführen |
— |
— |
ai:sandbox:manage |
Jobs in AI-Sandboxes ansehen und beenden |
— |
— |
mcp:use |
Diesem Benutzerkonto erlauben, mit OAuth auf den Remote-MCP-Server zuzugreifen |
— |
— |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
inference:providers:view |
Inference-Anbieter, Verbindungen, Erkennung und Kontingent ansehen |
— |
API, MCP |
inference:providers:manage |
Inference-Anbieter verbinden, aktualisieren, synchronisieren, routen und trennen |
— |
API, MCP |
inference:models:manage |
Inference-Modelle erstellen, veröffentlichen, ersetzen und löschen |
— |
API, MCP |
inference:limits:manage |
Standard- und benutzerbezogene Inference-Budgets konfigurieren |
— |
API, MCP |
inference:usage:view |
Systemweite und benutzerbezogene Inference-Nutzung ansehen |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
docker:containers:view |
Docker-Container ansehen |
Ressource, Ordner |
API, MCP |
docker:containers:create |
Container erstellen und duplizieren |
Ressource, Ordner |
API, MCP |
docker:containers:edit |
Einstellungen und Konfiguration von Containern bearbeiten |
Ressource, Ordner |
API, MCP |
docker:containers:manage |
Container starten, stoppen, neu starten, beenden und neu erstellen |
Ressource, Ordner |
API, MCP |
docker:containers:environment |
Umgebungsvariablen von Containern ändern |
Ressource, Ordner |
API, MCP |
docker:containers:link |
Anderen Workloads erlauben, über einen Container-Link einen Port eines Containers oder Deployments zu erreichen |
Ressource, Ordner |
API, MCP |
docker:containers:delete |
Container entfernen |
Ressource, Ordner |
API, MCP |
docker:containers:console |
Interaktive Konsole in Containern öffnen |
Ressource, Ordner |
API, MCP |
docker:containers:files:read |
Dateien in Containern durchsuchen und lesen |
Ressource, Ordner |
API, MCP |
docker:containers:files:write |
Dateien in Containern erstellen, bearbeiten, verschieben und löschen |
Ressource, Ordner |
API, MCP |
docker:containers:export |
Portable Container-Archive exportieren |
Ressource, Ordner |
API, MCP |
docker:containers:secrets |
Verschlüsselte Secrets ansehen und verwalten |
Ressource, Ordner |
API, MCP |
docker:containers:webhooks |
Webhook-Update-Auslöser von Containern ansehen und verwalten |
Ressource, Ordner |
API, MCP |
docker:containers:mounts |
Mounts von Containern und Deployments hinzufügen, entfernen oder ändern und einem Workload mit Host-Bind-Mounts ein neues Image oder einen neuen Befehl geben |
Ressource, Ordner |
API, MCP |
docker:containers:migrate |
Container und Deployments zwischen Docker Nodes migrieren |
Ressource, Ordner |
API, MCP |
docker:availability:manage |
Workload Availability über mehrere Nodes aktivieren, skalieren, heilen und deaktivieren |
Ressource, Ordner |
API, MCP |
docker:folders:manage |
Container, Deployments, Compose-Projekte, Netzwerke, Volumes und Images in Ordnern organisieren |
Ordner |
API, MCP |
Container-Logs, -Statistiken, -Prozesse und -Inspect werden von docker:containers:view abgedeckt; es gibt keinen separaten Log-Scope. Das Duplizieren eines Containers und sein Neuerstellen mit geänderten Einstellungen erfordern zusätzlich zum Erstellungs- oder Verwaltungszugriff docker:containers:environment und docker:containers:secrets. Das Beziehen des Images beim Erstellen eines Containers oder Deployments wird durch docker:containers:create am Ziel abgedeckt; docker:images:pull wird nur benötigt, um Images eigenständig zu beziehen. Eine Datenbank- oder Speicherverbindung an einem Deployment erfordert außerdem docker:containers:manage darauf, weil jede Verbindungsänderung es ausrollt, sowie docker:containers:edit, wenn die Verbindung seine Umgebung ändert. docker:containers:manage autorisiert Starten, Stoppen, Neustarten, Beenden und Neuerstellen gemeinsam; einen Scope nur für den Neustart gibt es nicht. Diese Scopes gelten auch für eigenständige Container, die Opfield erkannt, aber nicht erstellt hat. Siehe Workloads betreiben, ohne sie zu übernehmen.
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
docker:compose:view |
Compose-Projekte, Dienste, Monitoring, Logs, Revisionen und Aktivität erkennen und prüfen |
Ressource, Ordner |
API, MCP |
docker:compose:create |
Verwaltete Compose-Projekte validieren und bereitstellen; die Übernahme erfordert außerdem Manage Compose Projects |
Ressource, Ordner |
API, MCP |
docker:compose:manage |
Projekte übernehmen und Lebenszyklus, Revisionen, Secrets und Bindings verwalten |
Ressource, Ordner |
API, MCP |
docker:compose:delete |
Compose-Projekte löschen oder destruktive Aktionen zum Herunterfahren bzw. Löschen von Volumes ausführen |
Ressource, Ordner |
API, MCP |
Externe Compose-Projekte sind schreibgeschützt: docker:compose:view deckt ihr Inventar, ihr Monitoring und ihre zusammengefassten Logs ab, während Lebenszyklusaktionen erst nach der Übernahme verfügbar werden. Einzelne Container, die zu einem Compose-Projekt gehören, können über Container-Scopes nicht gestartet, gestoppt, neu gestartet, bearbeitet oder gelöscht werden.
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
docker:images:view |
Docker-Images ansehen |
Ressource, Ordner |
API, MCP |
docker:images:pull |
Docker-Images beziehen |
Ressource, Ordner |
API, MCP |
docker:images:delete |
Docker-Images entfernen und bereinigen (Prune) |
Ressource, Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
docker:volumes:view |
Docker-Volumes ansehen |
Ressource, Ordner |
API, MCP |
docker:volumes:create |
Docker-Volumes erstellen |
Ressource, Ordner |
API, MCP |
docker:volumes:edit |
Docker-Volumes umbenennen, neu beschriften, in der Größe ändern und übernehmen |
Ressource, Ordner |
API, MCP |
docker:volumes:delete |
Docker-Volumes entfernen |
Ressource, Ordner |
API, MCP |
docker:volumes:export |
Portable Archive von Docker-Volumes exportieren |
Ressource, Ordner |
API, MCP |
docker:volumes:files:read |
Dateien in Docker-Volumes durchsuchen, öffnen und herunterladen |
Ressource, Ordner |
API, MCP |
docker:volumes:files:write |
Dateien in Docker-Volumes erstellen, bearbeiten, hochladen, verschieben und löschen |
Ressource, Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
docker:networks:view |
Docker-Netzwerke ansehen |
Ressource, Ordner |
API, MCP |
docker:networks:create |
Docker-Netzwerke erstellen |
Ressource, Ordner |
API, MCP |
docker:networks:edit |
Container verbinden und trennen |
Ressource, Ordner |
API, MCP |
docker:networks:delete |
Docker-Netzwerke entfernen |
Ressource, Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
docker:registries:view |
Docker-Registries ansehen |
— |
API, MCP |
docker:registries:create |
Docker-Registries hinzufügen |
— |
API, MCP |
docker:registries:edit |
Einstellungen von Docker-Registries bearbeiten |
— |
API, MCP |
docker:registries:delete |
Docker-Registries entfernen |
— |
API, MCP |
docker:registries:internal:pull |
Veraltet. Lässt die API-Tokens des Benutzers diese Repositories ohne Workload-Zugriff beziehen |
Ressource |
API, MCP |
docker:registries:internal:push |
Veraltet. Lässt die API-Tokens des Benutzers ohne Workload-Zugriff in diese Repositories übertragen |
Ressource |
API, MCP |
Der Zugriff eines API-Tokens auf die interne Registry ist eine Einstellung des Tokens selbst (Internal registry), kein Scope. Der Eigentümer kann einem Token Pull geben, wenn er einen Docker-Workload oder ein Image ansehen kann, und Push, wenn er einen Workload ändern kann; jede Anfrage wird gegen die aktuellen Berechtigungen des Eigentümers geprüft.
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
docker:tasks |
Fortschritt von Docker-Tasks ansehen |
Ressource |
API, MCP |
docker:tasks:manage |
Aktive Docker-Tasks zwangsweise abbrechen |
Ressource |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
databases:view |
Gespeicherte Datenbankverbindungen ansehen |
Ressource, Ordner |
API, MCP |
databases:create |
Gespeicherte Datenbankverbindungen erstellen |
Ressource, Ordner |
API, MCP |
databases:edit |
Gespeicherte Datenbankverbindungen bearbeiten |
Ressource, Ordner |
API, MCP |
databases:bind |
Container, Deployments und Compose-Dienste mit verwalteten Datenbanken verbinden, ohne die Datenbank zu bearbeiten; der Workload benötigt außerdem seine eigenen Berechtigungen |
Ressource, Ordner |
API, MCP |
databases:delete |
Gespeicherte Datenbankverbindungen löschen |
Ressource, Ordner |
API, MCP |
databases:query:read |
Tabellen und Schlüssel durchsuchen und schreibgeschützte Datenbankabfragen ausführen |
Ressource, Ordner |
API, MCP |
databases:query:write |
Einfügen, aktualisieren, löschen und Schreibabfragen gegen Datenbanken ausführen |
Ressource, Ordner |
API, MCP |
databases:query:admin |
Administrative oder DDL-Datenbankbefehle ausführen |
Ressource, Ordner |
API, MCP |
databases:credentials:reveal |
Gespeicherte Datenbank-Zugangsdaten und Verbindungsstrings anzeigen |
Ressource, Ordner |
API, MCP |
databases:folders:manage |
Datenbankordner erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
databases:backups:view |
Backup-Richtlinien und Laufverlauf von Datenbanken ansehen |
Ressource, Ordner |
API, MCP |
databases:backups:manage |
Backup-Richtlinien erstellen, bearbeiten und löschen sowie Laufverlauf löschen |
Ressource, Ordner |
API, MCP |
databases:backups:run |
Backup-Läufe starten und abbrechen |
Ressource, Ordner |
API, MCP |
databases:backups:restore |
Ein Backup in eine neue oder leere Zieldatenbank wiederherstellen |
Ressource, Ordner |
API, MCP |
nodes:backups:execute |
Einen Storage Node als Ausführenden für Backup- und Wiederherstellungsjobs verwenden |
Ressource, Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
storage:view |
Speicherverbindungen, verwalteten Speicher und deren Status ansehen |
Ressource, Ordner |
API, MCP |
storage:create |
Speicherverbindungen und verwalteten Speicher erstellen |
Ressource, Ordner |
API, MCP |
storage:edit |
Speicherverbindungen und verwalteten Speicher bearbeiten, Bereitstellung neu starten oder wiederholen |
Ressource, Ordner |
API, MCP |
storage:delete |
Speicherverbindungen und verwalteten Speicher löschen |
Ressource, Ordner |
API, MCP |
storage:credentials:reveal |
Gespeicherte Speicher-Zugangsdaten anzeigen |
Ressource, Ordner |
API, MCP |
storage:credentials:use |
Backups und Speicher-Kopieraufträge gespeicherte Speicher-Zugangsdaten verwenden lassen, ohne sie anzuzeigen |
Ressource, Ordner |
API, MCP |
storage:iam |
Zugriffsschlüssel für verwalteten Speicher erstellen, widerrufen, importieren und einfrieren sowie Workload-Verbindungen zwischen Clustern verschieben |
Ressource, Ordner |
API, MCP |
storage:bind |
Container und Deployments mit verwaltetem Speicher verbinden, ohne Zugriffsschlüssel auszustellen; die eigenen Berechtigungen des Workloads sind ebenfalls erforderlich |
Ressource, Ordner |
API, MCP |
storage:objects:read |
Buckets und Objekte auflisten, Metadaten lesen, Objekte herunterladen und Download-Links erstellen |
Ressource, Ordner |
API, MCP |
storage:objects:write |
Objekte hochladen, Präfixe erstellen und Objekte löschen |
Ressource, Ordner |
API, MCP |
storage:objects:admin |
Buckets erstellen und löschen |
Ressource, Ordner |
API, MCP |
storage:folders:manage |
Speicherordner erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
notifications:alerts:view |
Alarmregeln für Benachrichtigungen ansehen |
— |
API, MCP |
notifications:alerts:manage |
Alarmregeln für Benachrichtigungen erstellen, bearbeiten und löschen |
— |
API, MCP |
notifications:webhooks:view |
Webhooks für Benachrichtigungen und ihre Zustellversuche ansehen |
— |
API, MCP |
notifications:webhooks:manage |
Webhooks für Benachrichtigungen erstellen, bearbeiten, testen und löschen |
— |
API, MCP |
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
logs:environments:view |
Externe Logging-Umgebungen ansehen |
Ressource, Ordner |
API, MCP |
logs:environments:create |
Logging-Umgebungen erstellen |
Ressource, Ordner |
API, MCP |
logs:environments:edit |
Logging-Umgebungen und Schemas bearbeiten |
Ressource, Ordner |
API, MCP |
logs:environments:delete |
Logging-Umgebungen löschen |
Ressource, Ordner |
API, MCP |
logs:environments:folders:manage |
Ordner für Logging-Umgebungen erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
logs:tokens:view |
Logging-Aufnahme-Tokens ansehen |
Ressource, Ordner |
API, MCP |
logs:tokens:create |
Logging-Aufnahme-Tokens erstellen |
Ressource, Ordner |
API, MCP |
logs:tokens:delete |
Logging-Aufnahme-Tokens widerrufen |
Ressource, Ordner |
API, MCP |
logs:schemas:view |
Wiederverwendbare Logging-Schemas ansehen |
Ressource, Ordner |
API, MCP |
logs:schemas:create |
Wiederverwendbare Logging-Schemas erstellen |
Ressource, Ordner |
API, MCP |
logs:schemas:edit |
Wiederverwendbare Logging-Schemas bearbeiten |
Ressource, Ordner |
API, MCP |
logs:schemas:delete |
Wiederverwendbare Logging-Schemas löschen |
Ressource, Ordner |
API, MCP |
logs:schemas:folders:manage |
Ordner für Logging-Schemas erstellen, neu ordnen und entfernen |
Ordner |
API, MCP |
logs:read |
Externe Logs durchsuchen und prüfen |
Ressource, Ordner |
API, MCP |
Scopes für Logging-Tokens und die Log-Suche werden durch die ID der Logging-Umgebung qualifiziert; ihre Ordnerberechtigungen werden über die Ordner der Logging-Umgebungen aufgelöst.
| Scope |
Beschreibung |
Einschränkungen |
Tokens |
status-page:view |
Konfiguration der Statusseite, bereitgestellte Dienste, Vorfälle und Vorschau ansehen |
— |
API, MCP |
status-page:manage |
Einstellungen der Statusseite und bereitgestellte Dienste bearbeiten |
— |
API, MCP |
status-page:incidents:create |
Manuelle Vorfälle erstellen und automatische Vorfälle übernehmen |
— |
API, MCP |
status-page:incidents:update |
Details von Vorfällen bearbeiten und Updates zur Zeitleiste eines Vorfalls veröffentlichen |
— |
API, MCP |
status-page:incidents:resolve |
Aktive Vorfälle der Statusseite lösen |
— |
API, MCP |
status-page:incidents:delete |
Gelöste Vorfälle der Statusseite löschen |
— |
API, MCP |
