Opfield définit 245 scopes de permissions. Les tableaux ci-dessous listent leurs noms exacts et les actions qu’ils autorisent. Attribuez les permissions via des groupes ou les permissions supplémentaires d’un utilisateur ; voir utilisateurs et groupes, Restreindre l’accès à un dossier et Jetons d’API, OAuth et MCP pour la configuration. Les scopes renommés ou supprimés en 2.11 sont listés sous Noms de scopes retirés.
- Restrictions : Ressource signifie que le scope prend en charge un qualificatif de ressource ; Dossier signifie qu’il prend aussi en charge un qualificatif de dossier, et Dossier seul signifie qu’il n’accepte qu’un qualificatif de dossier. App et Environnement sont les qualificatifs d’app décrits sous Apps. — signifie que le scope de base n’a pas de qualificatif de ressource. Pour les scopes d’intégration Git, la ressource est un connecteur, un groupe ou projet GitLab, ou un propriétaire ou dépôt GitHub ; voir Restrictions de l’intégration Git.
- Jetons : API signifie que le scope peut être délégué à un jeton d’API ou à OAuth pour l’API d’Opfield ; MCP signifie qu’il peut être délégué à OAuth pour la ressource MCP d’Opfield. — signifie qu’aucune des familles de jetons ordinaires ne l’accepte. Les permissions des utilisateurs et celles des jetons ne sont pas interchangeables.
- Une permission n’active pas une fonctionnalité du produit indisponible, ne contourne pas les exigences de licence et n’accorde ni identifiants ni privilèges chez le fournisseur externe.
- L’accès délégué est limité par les permissions effectives actuelles de l’utilisateur propriétaire. L’éligibilité d’un scope à MCP ne signifie pas qu’un outil correspondant existe.
- Les jetons d’API et autorisations OAuth pour l’API ou le MCP d’Opfield peuvent porter chaque scope, à l’exception des scopes réservés aux utilisateurs d’AI Workspace et des bacs à sable d’IA (
ai:workspace:use, feat:ai:configure, ai:skills:manage et ai:sandbox:*), de mcp:use, d’admin:users:impersonate et d’integrations:gitlab:sandbox:clone. Les jetons d’API et les autorisations OAuth eux-mêmes ne peuvent être créés que depuis une session interactive.
Une permission de base comme proxy:view couvre toutes les routes. Une permission qualifiée comme proxy:view:<routeId> couvre une route ; proxy:view:folder/<folderId> couvre les routes du dossier sélectionné et de ses sous-dossiers. Les scopes des Routes, de Pages, du stockage, des bases de données et de Docker, ainsi que chaque scope de création, acceptent aussi node/<nodeId> pour les ressources d’un nœud.
Le qualificatif dépend du type de ressource. Les scopes des conteneurs Docker utilisent <nodeId> pour un nœud ou <nodeId>/<stableResourceId> pour un conteneur ou un déploiement précis. Les permissions Pages qualifiées utilisent l’identifiant du projet, y compris pour les opérations sur ses déploiements, ses tags et ses jetons de déploiement. Les scopes de la PKI interne utilisent l’identifiant de la CA. Sélectionnez la cible dans l’éditeur de permissions plutôt que d’utiliser l’identifiant d’un autre type de ressource.
Opfield résout un droit sur un dossier à chaque requête : il couvre les ressources présentes dans le dossier à ce moment-là, celles qui y sont créées ou déplacées plus tard, et rien de ce qui en a été sorti. Pour les permissions de création, une restriction par dossier sélectionne le dossier de destination, et non une ressource qui n’a pas encore été créée. La gestion des dossiers et les opérations sur les ressources sont des permissions distinctes : gérer un dossier n’accorde pas en soi l’accès à chaque élément qu’il contient, et déplacer un élément nécessite toujours le scope de modification ou de gestion propre à l’élément. Un scope de gestion des dossiers limité à un dossier, comme proxy:folders:manage:folder/<folderId>, gère les sous-dossiers de ce dossier et ce qui y est placé, mais pas le dossier lui-même ni le niveau racine.
Les jetons d’API et les autorisations OAuth sont résolus en deux étapes : leurs propres restrictions de dossiers et de nœuds sont d’abord développées, puis le résultat est limité par les accès actuels du propriétaire. Un jeton n’atteint donc jamais une ressource que son propriétaire ne peut pas atteindre, et un droit de création ne compte jamais comme un droit de consultation lorsqu’il est délégué. Lorsqu’un jeton demande un scope large que le propriétaire ne détient que pour certaines ressources, Opfield restreint le jeton à ces ressources.
Chaque scope appartient à une famille désignée par son plus long préfixe disposant d’un scope de consultation : proxy:* appartient à proxy:view, docker:containers:* à docker:containers:view, nodes:* à nodes:details, et docker:tasks:manage à docker:tasks. Tout scope d’action implique le scope de consultation de sa famille avec le même qualificatif, y compris les scopes de suppression. Par exemple, proxy:edit:<routeId> permet à son détenteur de voir cette route, docker:containers:manage:<nodeId> lui permet de voir chaque conteneur de ce nœud, et databases:query:read:<databaseId> affiche cette base dans la liste des bases sans accorder databases:view global.
Les scopes de création n’impliquent aucune consultation : chaque scope comportant une partie create, comme proxy:create, docker:containers:create ou pki:templates:create, ainsi que docker:images:pull, ssl:cert:issue et pki:cert:issue. Cela vaut quel que soit le qualificatif — large, un dossier ou un nœud — ; un utilisateur qui ne dispose que de proxy:create:folder/<folderId> peut donc créer des routes dans ce dossier mais ne voit pas les routes qui s’y trouvent déjà. Les boîtes de dialogue de création affichent malgré tout les dossiers et nœuds de destination qu’un tel utilisateur peut choisir. Avec Auto-assign permissions for created resources activé, ce qui est le cas par défaut, le créateur conserve la consultation de chaque ressource qu’il crée ; voir Restreindre l’accès à un dossier. La seule exception est hosting:snapshots:create:<vmId>, qui conserve la consultation des instantanés de cette VM.
Quelques règles explicites complètent le tableau :
- Niveaux d’accès :
storage:objects:admin inclut write, qui inclut read ; databases:query:admin inclut write, qui inclut read ; storage:credentials:reveal inclut storage:credentials:use.
ssl:cert:issue implique ssl:cert:renew ; pki:cert:export implique pki:cert:deploy ; docker:containers:secrets implique docker:containers:environment ; databases:edit implique databases:bind ; storage:iam implique storage:bind.logs:read et logs:tokens:view (et donc logs:tokens:delete) impliquent logs:environments:view ; nodes:manage implique nodes:config:view, qui implique nodes:details ; inference:models:manage implique inference:providers:view ; docker:availability:manage implique docker:containers:view.- Les scopes d’arborescences de dossiers (
*:folders:manage), nodes:backups:execute, proxy:maintenance:bypass et les anciens scopes du registre interne docker:registries:internal:pull et :push n’impliquent aucune consultation.
- Un scope de consultation n’implique jamais la consultation d’une autre famille ;
proxy:templates:view n’accorde pas proxy:view.
Chaque type de ressource possède sa propre arborescence de dossiers. Un dossier dans Routes ne couvre pas les conteneurs, même lorsqu’un dossier Docker porte le même nom.
| Ressources |
Restriction par dossier |
Arborescence gérée avec |
| Routes |
Oui |
proxy:folders:manage |
| Domaines |
Oui |
domains:folders:manage |
| Certificats SSL |
Oui |
ssl:cert:folders:manage |
| Projets Pages |
Oui |
pages:folders:manage |
| Nœuds |
Oui |
nodes:folders:manage |
| Groupes d’ingress |
Oui, dans l’arborescence des dossiers de nœuds ; un groupe se trouve dans un dossier de nœuds, et les permissions sur les nœuds ne le révèlent pas |
nodes:folders:manage |
| Conteneurs et Deployments Docker |
Oui |
docker:folders:manage |
| Projets Compose, réseaux Docker, volumes Docker, images Docker |
Oui ; chaque type a une arborescence distincte |
docker:folders:manage |
| Bases de données : connexions externes et bases managées |
Oui |
databases:folders:manage |
| Stockage : connexions de stockage et stockage managé |
Oui |
storage:folders:manage |
| Environnements de journalisation ; schémas de journalisation |
Oui |
logs:environments:folders:manage ; logs:schemas:folders:manage |
| Utilisateurs ; groupes de permissions |
Oui |
admin:users:folders:manage ; admin:groups:folders:manage |
| Autorités de certification de la PKI interne |
Oui ; un dossier contient des hiérarchies de CA entières, et un droit couvre chaque CA racine du dossier et ses intermédiaires |
pki:ca:folders:manage |
| Certificats de la PKI interne |
Oui |
pki:cert:folders:manage |
| Modèles nginx |
Oui |
proxy:templates:folders:manage |
| Modèles de certificats |
Les dossiers ne servent qu’à organiser la liste ; les scopes des modèles de certificats ne sont pas restreints à des ressources |
pki:templates:folders:manage |
| Sauvegardes de bases de données |
Via le dossier de la base |
— |
| Jetons d’ingestion de journalisation et recherche de journaux |
Via le dossier de l’environnement de journalisation |
— |
| Workload Availability |
Via le dossier du conteneur ou de Compose |
— |
Exécuteurs de sauvegardes (nodes:backups:execute) |
Via le dossier du nœud |
— |
| Apps (qui prennent à la place des qualificatifs d’app et d’environnement), listes d’accès, registres Docker, tâches Docker, notifications, page de statut, SIEM, intégrations, comptes et VM d’hébergeurs, inférence, diagnostics d’Opfield, maintenance, licence et paramètres |
Non |
— |
Les scopes sans prise en charge des dossiers sont globaux ou, lorsque le catalogue indique Ressource, restreints à une ressource. Les dossiers d’instantanés d’hébergement ne servent qu’à organiser les instantanés ; ce ne sont pas des frontières d’accès.
Les scopes d’intégration Git peuvent être limités à un connecteur et, pour GitLab et GitHub, à des groupes, projets, propriétaires ou dépôts qu’il contient. Les qualificatifs sont des identifiants stables du fournisseur, jamais des noms ou des chemins ; renommer ou déplacer un groupe ou un dépôt ne modifie donc jamais un droit.
| Qualificatif |
Couvre |
<scope>:<connectorId> |
Chaque dépôt de ce connecteur |
<scope>:<connectorId>/group/<groupId> |
GitLab : le groupe, ses sous-groupes et chaque projet qu’ils contiennent. Opfield lit auprès de GitLab les groupes parents d’un projet et les met en cache pendant quelques minutes ; un projet déplacé suit donc son nouveau groupe |
<scope>:<connectorId>/project/<projectId> |
GitLab : ce projet |
<scope>:<connectorId>/owner/<ownerId> |
GitHub : chaque dépôt de cette organisation ou de cet utilisateur |
<scope>:<connectorId>/repo/<repoId> |
GitHub : ce dépôt |
- Quels scopes :
view, use, repo:read et repo:write de GitLab et GitHub, ainsi que integrations:gitlab:sandbox:clone, acceptent chaque qualificatif de leur fournisseur. Les scopes Git génériques n’acceptent que le connecteur. integrations:<provider>:manage est large ou limité à un connecteur : la gestion d’une connexion — ses paramètres, ses jetons, sa liste d’autorisation des dépôts, sa synchronisation, son test et sa suppression — le nécessite sur ce connecteur, et la création d’un connecteur le nécessite au sens large. Un droit sur un groupe, un propriétaire, un projet ou un dépôt ne permet jamais la gestion du connecteur.
- Correspondance : une opération sur un dépôt est autorisée par le scope large, le qualificatif du connecteur, tout groupe ou propriétaire qui contient le dépôt, ou le projet ou dépôt exact. La consultation implicite fonctionne par qualificatif :
integrations:gitlab:repo:write:<connectorId>/project/42 affiche aussi le projet 42. Les qualificatifs de dossier ne s’appliquent pas aux intégrations.
- Ce qui est vérifié : chaque opération sur un dépôt vérifie le dépôt — fichiers, arborescences, branches, commits, pipelines CI, journaux et variables des jobs, webhooks, jetons de déploiement, paramètres du registre, clones en bac à sable et sources de build Docker et Pages —, dans l’API REST, AI Workspace et MCP de la même manière.
- Identifiants : Opfield utilise l’identifiant propre au connecteur lorsque
integrations:<provider>:use couvre le dépôt de la même manière, et l’identifiant personnel de l’appelant sinon. À défaut de l’un et de l’autre, les utilisateurs d’AI Workspace sont invités à autoriser un identifiant personnel, et les autres appelants reçoivent 403 en indiquant integrations:<provider>:use et le dépôt.
- Projets masqués : un projet GitLab hors du droit de l’appelant répond exactement comme un projet non synchronisé (
404, sans chemin). Les écritures, les secrets, les clones en bac à sable et la décision relative à l’identifiant lisent à neuf auprès du fournisseur la filiation des groupes et la propriété des dépôts ; les lectures peuvent utiliser une valeur en cache jusqu’à cinq minutes, et la propriété GitHub est mise en cache par identifiant de dépôt, jamais par chemin. Les événements de modification des connecteurs via le WebSocket n’atteignent que les appelants autorisés à voir ce connecteur.
- Listes : les listes de connecteurs contiennent les connecteurs sur lesquels l’appelant détient un scope Git quelconque ; un connecteur vu uniquement via des droits plus restreints est renvoyé sans sa liste d’autorisation. Les listes de projets et de dépôts ne contiennent que ce que couvrent les droits.
- Sources de build : la configuration d’une source de build Docker ou Pages nécessite
integrations:<provider>:use sur le dépôt, avec tout qualificatif qui le couvre, en plus des permissions propres à la charge de travail. repo:read, view au sens large et un identifiant personnel ne sont pas nécessaires, car les builds utilisent l’identifiant du connecteur. Le sélecteur de source liste les connecteurs et dépôts couverts par les scopes Git de l’appelant, puisque use implique view. Un build manuel revérifie le use de l’appelant sur le dépôt enregistré. Les sources enregistrées avant 2.11 continuent de construire automatiquement comme avant ; une source créée ou enregistrée à nouveau après la mise à jour ne construit via l’interrogation périodique et les webhooks que tant que le compte qui l’a enregistrée détient toujours use sur le dépôt, et enregistre sinon un build annulé Build paused: <user> no longer has use on <repo> jusqu’au retour de cet accès ou jusqu’à ce qu’une personne disposant de use enregistre à nouveau la source.
- Jetons et autorisations OAuth : un scope Git délégué est borné par le propriétaire, qualificatif par qualificatif. Un scope de jeton plus large est restreint aux qualificatifs du propriétaire, et un scope de jeton limité à un groupe, un propriétaire, un projet ou un dépôt est conservé lorsque le propriétaire détient le même scope, ou un scope qui l’implique, n’importe où sur ce connecteur. Comme l’appartenance est une donnée du fournisseur, chaque opération sur un dépôt effectuée par un appelant de type jeton ou OAuth nécessite que le jeton et les scopes actuels du propriétaire couvrent tous deux le dépôt : un jeton limité au projet P fonctionne tant que son propriétaire détient le groupe qui contient P, et un jeton limité au groupe G dont le propriétaire ne détient que le projet P n’atteint que P. Ces scopes de jeton restreints ne comptent jamais lorsque le jeton accorde des permissions à des utilisateurs ou à des groupes.
L’éditeur de groupe, les permissions supplémentaires des utilisateurs, le formulaire des jetons d’API et le consentement OAuth et MCP proposent ces restrictions sous chaque connecteur, avec un sélecteur de recherche pour les groupes et projets ou les propriétaires et dépôts. Le sélecteur lit GET /api/integrations/{provider}/{connectorId}/scope-targets?search=&limit=50, où provider vaut gitlab ou github, et affiche les libellés des qualificatifs enregistrés via GET /api/integrations/{provider}/{connectorId}/scope-targets/resolve?ids=group/123,project/456. Les deux points de terminaison nécessitent integrations:<provider>:view sur le connecteur ou sur un élément qu’il contient, et ne renvoient que les cibles que l’appelant peut consulter et que la liste d’autorisation du connecteur inclut. Ils partagent une limite de 60 requêtes par minute et par compte, au-delà de laquelle ils renvoient 429 SCOPE_TARGET_RATE_LIMITED avec Retry-After, et une requête effectue au plus 60 recherches non mises en cache auprès du fournisseur ; les cibles suivantes conservent leurs identifiants bruts. Une cible qui n’existe plus est marquée missing et affichée comme Unavailable ; un qualificatif enregistré que l’appelant ne peut pas consulter conserve son identifiant brut comme libellé.
Opfield 2.11 a renommé, fusionné ou supprimé les scopes ci-dessous. La mise à jour a réécrit chaque droit enregistré — groupes, permissions supplémentaires des utilisateurs, jetons d’API et autorisations OAuth — en conservant chaque qualificatif ; nodes:config:edit:<nodeId> est ainsi devenu nodes:manage:<nodeId>. Pour que personne ne perde d’accès, les détenteurs de pki:ca:create:root ont aussi reçu pki:ca:edit et pki:ca:export ; les détenteurs de integrations:github:view ou integrations:git:view ont reçu :repo:read ; les détenteurs de integrations:github:manage ou integrations:git:manage ont reçu :repo:read et :repo:write ; et les détenteurs de docker:volumes:create au sens large ou au niveau d’un nœud (par exemple docker:volumes:create:<nodeId>) ont reçu docker:volumes:edit avec le même qualificatif ; les droits de création au niveau d’un dossier et les droits limités à la suppression ne l’ont pas reçu.
Pendant deux versions, Opfield accepte encore les anciens noms en entrée et les réécrit de la même manière : le paramètre OAuth scope, la création et la mise à jour des jetons d’API, la création et la mise à jour des groupes de permissions, les permissions supplémentaires des utilisateurs et les modifications d’autorisations OAuth. Une requête dont tous les scopes ont été supprimés est refusée. Les nouveaux jetons d’API et les nouvelles demandes OAuth reçoivent aussi les ajouts ci-dessus lorsque le demandeur les détient — par exemple, un jeton demandé avec integrations:github:manage reçoit aussi repo:read —, et l’écran de consentement les affiche afin qu’ils puissent être décochés. Les scopes qui nécessitent une approbation manuelle, comme repo:write ou pki:ca:export, ne sont jamais ajoutés en entrée. Les vérifications de permissions n’utilisent que les noms actuels ; mettez donc à jour les scripts, les clients OAuth et les définitions d’infrastructure en tant que code avant la suppression des alias.
| Retiré |
Remplacement |
ssl:cert:revoke, ssl:cert:export |
Supprimés ; ils n’ont jamais été appliqués |
notifications:view |
notifications:alerts:view et notifications:webhooks:view |
notifications:manage |
notifications:alerts:manage et 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 |
Chaque scope logs:* |
docker:containers:config |
Supprimé. La duplication et la recréation nécessitent docker:containers:environment et docker:containers:secrets ; l’adresse de service d’un nœud Docker nécessite 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 |
Supprimé ; le passage en mode brut nécessite 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 |
Certains remplacements sont plus larges que le scope qu’ils remplacent ; examinez donc les groupes, les permissions des utilisateurs, les jetons d’API et les autorisations OAuth qui les détenaient : integrations:gitlab:repo:write commite aussi des fichiers de dépôt et modifie la configuration CI, les variables, les webhooks et les paramètres du registre ; integrations:gitlab:repo:read lit aussi les fichiers du dépôt ; la permission manage d’un connecteur couvre ses paramètres, ses jetons, sa liste d’autorisation, son test et sa suppression ; nodes:manage installe aussi le Secure Runtime, modifie les adresses de service et contrôle les VM hébergées ; proxy:unrestricted lève à la fois les restrictions de la configuration avancée et de la configuration brute ; et notifications:webhooks:manage révèle aussi les URL, les en-têtes et les charges utiles d’envoi des webhooks. integrations:gitlab:variables:view est devenu integrations:gitlab:repo:read, qui lit les clés des variables mais pas leurs valeurs. Voir Mettre à jour depuis 2.10.
En 2.12.1, settings:gateway:view et settings:gateway:edit sont devenus settings:opfield:view et settings:opfield:edit. La mise à jour a réécrit chaque droit enregistré, y compris les jetons d’API et les autorisations OAuth ; les scripts et les clients OAuth doivent demander les nouveaux noms.
Autres changements de permissions en 2.11 :
- Nouveaux scopes :
pki:ca:edit (URL de la CA, validité maximale et répondeur OCSP) et pki:ca:export (export de la clé privée d’une CA), tous deux restreignables à une CA ; docker:volumes:edit (renommer, réétiqueter, redimensionner et adopter des volumes) ; integrations:github:repo:read, :repo:write, integrations:git:repo:read et :repo:write.
- Les fournisseurs Git partagent les mêmes verbes :
view liste les connecteurs, manage les configure, les teste et les synchronise, use utilise l’identifiant propre au connecteur, et repo:read et repo:write lisent ou modifient le contenu des dépôts. Chacun peut être limité à un connecteur et, pour GitLab et GitHub, à des groupes, projets, propriétaires ou dépôts ; voir Restrictions de l’intégration Git. Lister et lire les projets synchronisés de GitLab nécessite integrations:gitlab:view. repo:read de GitLab couvre les fichiers du dépôt, les pipelines CI et les journaux des jobs, ainsi que les clés des variables CI/CD, jamais leurs valeurs ; modifier les variables nécessite repo:write. Lire les valeurs des variables GitHub Actions nécessite integrations:github:repo:write. Les groupes intégrés viewer et operator ne reçoivent que integrations:gitlab:view.
- Modèles : l’écriture du contenu des modèles nginx nécessite
proxy:templates:manage et non plus proxy:raw:write. Le groupe intégré operator ne conserve que proxy:templates:view, car le contenu des modèles est de la configuration nginx brute.
- Les droits sur les dossiers se résolvent désormais pour
logs:tokens:* (via le dossier de l’environnement de journalisation) et docker:availability:manage (via le dossier du conteneur ou de Compose). Les autorités de certification, les certificats de la PKI interne et les modèles nginx peuvent être organisés en dossiers et accordés par dossier ; voir Prise en charge des dossiers par type de ressource.
- Consultation implicite : chaque permission d’action, sauf la création, implique la permission de consultation de sa famille avec le même qualificatif ; un droit limité à la suppression permet donc désormais aussi de lister et de consulter ces ressources ; voir Consultation implicite.
- Nouvelles permissions pour de nouvelles fonctionnalités :
diagnostics:view et diagnostics:logs, databases:backups:*, nodes:backups:execute et les scopes storage:*. Les groupes intégrés les ont reçues ; les groupes de permissions personnalisés non, accordez-les donc là où c’est nécessaire.
| Scope |
Description |
Restrictions |
Jetons |
pki:ca:view |
Consulter les autorités de certification racines et intermédiaires |
Ressource, Dossier |
API, MCP |
pki:ca:create:root |
Créer de nouvelles autorités de certification racines |
— |
API, MCP |
pki:ca:create:intermediate |
Créer des CA intermédiaires sous une racine |
Ressource |
API, MCP |
pki:ca:edit |
Modifier les URL de la CA, la validité maximale et le répondeur OCSP |
Ressource, Dossier |
API, MCP |
pki:ca:export |
Exporter une autorité de certification avec sa clé privée |
Ressource, Dossier |
API, MCP |
pki:ca:folders:manage |
Gérer les dossiers de CA. Seules les CA racines se déplacent, et leurs intermédiaires suivent ; déplacer une CA racine nécessite aussi pki:ca:edit sur celle-ci et sur la destination |
Dossier |
API, MCP |
pki:ca:revoke:root |
Révoquer des autorités de certification racines |
— |
API, MCP |
pki:ca:revoke:intermediate |
Révoquer des autorités de certification intermédiaires |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
pki:cert:view |
Consulter les certificats émis |
Ressource, Dossier |
API, MCP |
pki:cert:issue |
Émettre de nouveaux certificats |
Ressource |
API, MCP |
pki:cert:revoke |
Révoquer des certificats émis |
Ressource, Dossier |
API, MCP |
pki:cert:export |
Exporter des certificats et des clés |
Ressource, Dossier |
API, MCP |
pki:cert:deploy |
Rattacher ou lier des certificats serveur TLS aux routes ; nginx utilise la clé, l’appelant ne la voit jamais. La liaison dans le magasin SSL nécessite aussi ssl:cert:issue |
Ressource, Dossier |
API, MCP |
pki:cert:folders:manage |
Gérer les dossiers de certificats PKI ; déplacer un certificat nécessite aussi pki:cert:issue sur la CA émettrice |
Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
pki:templates:view |
Consulter les modèles de certificats |
— |
API, MCP |
pki:templates:create |
Créer des modèles de certificats |
— |
API, MCP |
pki:templates:edit |
Modifier des modèles de certificats |
— |
API, MCP |
pki:templates:delete |
Supprimer des modèles de certificats |
— |
API, MCP |
pki:templates:folders:manage |
Gérer les dossiers de modèles de certificats ; déplacer un modèle personnalisé nécessite aussi pki:templates:edit, et les modèles intégrés ne se déplacent jamais |
Dossier |
API, MCP |
Les scopes d’app acceptent deux qualificatifs : <appId> pour une app et env/<envId> pour l’un de ses environnements. La ligne d’accès In an app environment de l’éditeur de permissions les définit en même temps que des droits sur les dossiers pour les ressources de cet environnement ; voir Permissions des Apps.
Sans apps:view, une app reste visible par un utilisateur qui peut voir l’une de ses ressources grâce à ses propres droits, y compris un droit sur le dossier de l’environnement ou de l’app. Cet utilisateur ne voit que les environnements qui contiennent de telles ressources, et uniquement ces ressources, et Overview et Activity ne couvrent qu’elles. Les paramètres, les nœuds autorisés, la maintenance, les variables, la promotion et chaque action nécessitent toujours les scopes d’app. Voir Qui voit une app.
| Scope |
Description |
Restrictions |
Jetons |
apps:view |
Consulter toute l’app : tous ses environnements, la vue d’ensemble et l’activité ; les ressources nécessitent toujours leurs propres scopes de consultation. Sans lui, une app n’est visible qu’à travers les ressources que l’utilisateur peut voir |
App, Environnement |
API, MCP |
apps:create |
Créer des apps |
— |
API, MCP |
apps:edit |
Renommer l’app, ajouter, renommer et supprimer des environnements, et déplacer le marqueur Production |
App |
API, MCP |
apps:delete |
Supprimer l’app ; ses ressources continuent de s’exécuter et quittent l’app |
App |
API, MCP |
apps:env:manage |
Variables et secrets d’environnement, nœuds autorisés, maintenance et codes d’accès de l’environnement, et entrée ou sortie de ressources conjointement avec le scope de modification propre à la ressource |
App, Environnement |
API, MCP |
apps:promote |
Promouvoir dans l’environnement |
App, Environnement |
API, MCP |
apps:operate |
Arrêter, démarrer et isoler ; la maintenance de toute l’app nécessite ce scope sur l’app |
App, Environnement |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
domains:view |
Consulter les domaines gérés |
Ressource, Dossier |
API, MCP |
domains:create |
Créer des domaines gérés |
Ressource, Dossier |
API, MCP |
domains:edit |
Modifier des domaines gérés |
Ressource, Dossier |
API, MCP |
domains:delete |
Supprimer des domaines gérés |
Ressource, Dossier |
API, MCP |
domains:folders:manage |
Organiser les domaines gérés en dossiers |
Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
proxy:view |
Consulter et rechercher des routes d’ingress |
Ressource, Dossier |
API, MCP |
proxy:create |
Créer de nouvelles routes d’ingress |
Ressource, Dossier |
API, MCP |
proxy:edit |
Modifier la configuration des routes d’ingress |
Ressource, Dossier |
API, MCP |
proxy:delete |
Supprimer des routes d’ingress |
Ressource, Dossier |
API, MCP |
proxy:raw:read |
Consulter la configuration nginx brute |
Ressource, Dossier |
API, MCP |
proxy:raw:write |
Modifier la configuration nginx brute et faire passer des routes du mode géré au mode brut et inversement |
Ressource, Dossier |
API, MCP |
proxy:advanced |
Utiliser la configuration de proxy avancée |
Ressource, Dossier |
API, MCP |
proxy:unrestricted |
Enregistrer des extraits avancés et une configuration nginx brute sans les restrictions sur les directives dangereuses |
Ressource, Dossier |
API, MCP |
proxy:maintenance:bypass |
Créer des codes d’accès temporaires pour les routes en maintenance |
Ressource, Dossier |
API, MCP |
proxy:folders:manage |
Créer, réordonner et supprimer des dossiers de routes |
Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
pages:view |
Consulter les projets Pages, les Deployments, les tags, les aperçus et la consommation |
Ressource, Dossier |
API, MCP |
pages:create |
Créer des projets Pages statiques |
Ressource, Dossier |
API, MCP |
pages:edit |
Renommer des projets Pages et modifier leurs paramètres de conservation et de quota |
Ressource, Dossier |
API, MCP |
pages:delete |
Supprimer des projets Pages éligibles |
Ressource, Dossier |
API, MCP |
pages:deploy |
Créer et téléverser des Deployments statiques |
Ressource, Dossier |
API, MCP |
pages:deployments:manage |
Épingler, désépingler, nettoyer et supprimer des Deployments éligibles |
Ressource, Dossier |
API, MCP |
pages:tags:manage |
Créer, déplacer et supprimer des tags de projets Pages |
Ressource, Dossier |
API, MCP |
pages:tokens:manage |
Créer, restreindre et révoquer des identifiants de déploiement de projet |
Ressource, Dossier |
API, MCP |
pages:folders:manage |
Créer, réordonner et supprimer des dossiers de projets Pages |
Dossier |
API, MCP |
pages:settings:view |
Consulter le profil wildcard et les valeurs de stockage par défaut |
— |
API, MCP |
pages:settings:edit |
Configurer et migrer le profil wildcard de Pages et les valeurs de stockage par défaut |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
proxy:templates:view |
Consulter les modèles nginx |
Ressource, Dossier |
API, MCP |
proxy:templates:manage |
Créer, modifier et supprimer des modèles nginx, y compris leur contenu ; avec un qualificatif de dossier, créer aussi des modèles dans ce dossier |
Ressource, Dossier |
API, MCP |
proxy:templates:folders:manage |
Gérer les dossiers de modèles nginx ; déplacer un modèle personnalisé nécessite aussi proxy:templates:manage sur celui-ci et sur la destination, et les modèles intégrés ne se déplacent jamais |
Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
ssl:cert:view |
Consulter les certificats SSL |
Ressource, Dossier |
API, MCP |
ssl:cert:issue |
Provisionner des certificats ACME ou téléverser des certificats SSL ; les renouvelle aussi |
Ressource, Dossier |
API, MCP |
ssl:cert:renew |
Renouveler des certificats existants, terminer leur vérification DNS et définir le renouvellement automatique |
Ressource, Dossier |
API, MCP |
ssl:cert:folders:manage |
Organiser les certificats SSL en dossiers |
Dossier |
API, MCP |
ssl:cert:delete |
Supprimer des certificats SSL |
Ressource, Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
acl:view |
Consulter les listes de contrôle d’accès |
Ressource |
API, MCP |
acl:create |
Créer des listes de contrôle d’accès |
— |
API, MCP |
acl:edit |
Modifier des listes de contrôle d’accès |
Ressource |
API, MCP |
acl:delete |
Supprimer des listes de contrôle d’accès |
Ressource |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
nodes:details |
Consulter les nœuds gérés |
Ressource, Dossier |
API, MCP |
nodes:create |
Enrôler de nouveaux nœuds |
Ressource, Dossier |
API, MCP |
nodes:rename |
Renommer des nœuds |
Ressource, Dossier |
API, MCP |
nodes:delete |
Retirer des nœuds |
Ressource, Dossier |
API, MCP |
nodes:config:view |
Consulter la configuration nginx d’un nœud |
Ressource, Dossier |
API, MCP |
nodes:manage |
Modifier la configuration nginx d’un nœud, installer le secure runtime Docker, modifier les adresses de service et contrôler les VM hébergées |
Ressource, Dossier |
API, MCP |
nodes:logs |
Consulter les journaux du démon et de nginx d’un nœud |
Ressource, Dossier |
API, MCP |
nodes:console |
Ouvrir un shell interactif sur les nœuds |
Ressource, Dossier |
API, MCP |
nodes:files:read |
Parcourir, ouvrir, copier et télécharger les fichiers d’un nœud |
Ressource, Dossier |
API, MCP |
nodes:files:write |
Créer, modifier, téléverser, déplacer et supprimer les fichiers d’un nœud |
Ressource, Dossier |
API, MCP |
nodes:lock |
Empêcher la création de nouveaux proxy hosts ou conteneurs sur les nœuds sélectionnés |
Ressource, Dossier |
API, MCP |
nodes:folders:manage |
Créer, réordonner et supprimer des dossiers de nœuds |
Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
ingress:groups:view |
Consulter les groupes d’ingress, leurs membres et la livraison par membre ; y placer des routes et des domaines |
Dossier |
API, MCP |
ingress:groups:manage |
Créer, modifier et supprimer des groupes d’ingress et modifier leurs membres ; l’ajout d’un nœud nécessite aussi nodes:manage sur celui-ci |
Dossier |
API, MCP |
Les scopes des groupes d’ingress n’acceptent qu’un qualificatif de dossier de nœuds. Les permissions sur les nœuds ne révèlent pas les groupes d’ingress.
| Scope |
Description |
Restrictions |
Jetons |
admin:users |
Créer, modifier et supprimer des utilisateurs |
Ressource, Dossier |
API, MCP |
admin:users:impersonate |
Agir temporairement en tant qu’un autre utilisateur actif |
Ressource, Dossier |
— |
admin:users:folders:manage |
Créer, réordonner et supprimer des dossiers d’utilisateurs |
Dossier |
API, MCP |
admin:groups |
Créer, modifier et supprimer des groupes de permissions |
Ressource, Dossier |
API, MCP |
admin:groups:folders:manage |
Créer, réordonner et supprimer des dossiers de groupes de permissions |
Dossier |
API, MCP |
admin:audit |
Consulter le journal d’audit |
— |
API, MCP |
audit:siem:view |
Consulter les destinations SIEM et l’historique d’envoi de l’audit |
— |
API, MCP |
audit:siem:manage |
Configurer les destinations SIEM et contrôler les envois de l’audit |
— |
API, MCP |
admin:system |
Administration au niveau du système (protégée) |
— |
API, MCP |
admin:details:certificates |
Consulter en lecture seule la PKI système interne et les certificats SSL |
— |
API, MCP |
admin:update |
Rechercher et appliquer des mises à jour |
— |
API, MCP |
admin:alerts |
Consulter et gérer les alertes |
— |
API, MCP |
diagnostics:view |
Lire l’état propre à Opfield et son historique à la minute sur 48 heures : CPU, mémoire et disque de l’hôte, processus serveur, son PostgreSQL et son Redis, conteneurs de la pile, tâches d’arrière-plan et latence de l’API. Détenu par les groupes d’administration intégrés |
— |
API, MCP |
diagnostics:logs |
Lire les journaux des conteneurs propres à Opfield (app, PostgreSQL, Redis, Relay, registry) et de la dernière exécution de mise à jour ; implique diagnostics:view. Détenu par les groupes d’administration intégrés |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
settings:opfield:view |
Consulter les paramètres de provisionnement à la connexion et du plan de contrôle externe |
— |
API, MCP |
settings:opfield:edit |
Modifier les paramètres de provisionnement à la connexion et du plan de contrôle externe |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
integrations:gitlab:view |
Consulter les connecteurs GitLab configurés, l’état de synchronisation et les projets synchronisés |
Ressource |
API, MCP |
integrations:gitlab:manage |
Créer, modifier, faire tourner les identifiants de, synchroniser et supprimer des connecteurs GitLab |
Ressource |
API, MCP |
integrations:gitlab:use |
Utiliser l’identifiant du connecteur pour des opérations GitLab autorisées par ailleurs, et configurer des sources de build Docker et Pages à partir d’un projet |
Ressource |
API, MCP |
integrations:gitlab:repo:read |
Lire les fichiers des dépôts, les pipelines CI et les journaux des jobs, ainsi que les clés des variables CI/CD (jamais leurs valeurs) via les connecteurs GitLab |
Ressource |
API, MCP |
integrations:gitlab:repo:write |
Modifier les fichiers des dépôts, la configuration CI, les variables CI/CD, les webhooks et les enregistrements du registre via les connecteurs GitLab |
Ressource |
API, MCP |
integrations:gitlab:sandbox:clone |
Cloner les dépôts GitLab autorisés dans les bacs à sable d’IA |
Ressource |
— |
| Scope |
Description |
Restrictions |
Jetons |
integrations:github:view |
Consulter les connecteurs GitHub à jeton configurés |
Ressource |
API, MCP |
integrations:github:manage |
Créer, modifier, faire tourner les identifiants de, synchroniser et supprimer des connecteurs GitHub à jeton |
Ressource |
API, MCP |
integrations:github:use |
Utiliser l’identifiant du connecteur au lieu d’une autorisation GitHub personnelle, et configurer des sources de build Docker et Pages à partir d’un dépôt |
Ressource |
API, MCP |
integrations:github:repo:read |
Lister les dépôts et lire des fichiers via les connecteurs GitHub (sans les valeurs des variables Actions) |
Ressource |
API, MCP |
integrations:github:repo:write |
Modifier les fichiers et secrets des dépôts, et lire ou modifier les variables Actions, via les connecteurs GitHub |
Ressource |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
integrations:git:view |
Consulter les connecteurs Git génériques configurés |
Ressource |
API, MCP |
integrations:git:manage |
Créer, modifier, faire tourner les identifiants de, synchroniser et supprimer des connecteurs Git génériques |
Ressource |
API, MCP |
integrations:git:use |
Utiliser l’identifiant du connecteur au lieu d’une autorisation Git personnelle, et configurer des sources de build Docker et Pages à partir d’un dépôt |
Ressource |
API, MCP |
integrations:git:repo:read |
Lister les dépôts et lire des fichiers via les connecteurs Git génériques |
Ressource |
API, MCP |
integrations:git:repo:write |
Modifier les fichiers des dépôts via les connecteurs Git génériques |
Ressource |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
integrations:ssh:view |
Consulter les serveurs SSH externes configurés |
— |
API, MCP |
integrations:ssh:manage |
Ajouter et configurer des serveurs SSH externes et des hôtes de rebond |
— |
API, MCP |
integrations:ssh:use |
Exécuter des commandes approuvées sur les serveurs SSH externes configurés |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
integrations:cloudflare:view |
Consulter les connecteurs Cloudflare configurés et l’état de synchronisation |
— |
API, MCP |
integrations:cloudflare:sync |
Actualiser les zones Cloudflare et les capacités du jeton à l’aide de l’identifiant du connecteur |
— |
API, MCP |
integrations:cloudflare:manage |
Créer, modifier, tester, synchroniser, faire tourner les identifiants de et supprimer des connecteurs Cloudflare |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
integrations:hosting:view |
Consulter les comptes d’hébergeurs et l’état de connexion |
Ressource |
API, MCP |
integrations:hosting:manage |
Connecter, configurer et synchroniser des comptes d’hébergeurs |
Ressource |
API, MCP |
hosting:resources:view |
Consulter l’inventaire du fournisseur et les nœuds Opfield associés |
Ressource |
API, MCP |
hosting:resources:create |
Commander des VM chez le fournisseur et installer des rôles Opfield ; peut entraîner des frais |
Ressource |
API, MCP |
hosting:resources:power |
Démarrer, arrêter et redémarrer des VM ; tous les rôles hébergés sont affectés |
Ressource |
API, MCP |
hosting:resources:resize |
Modifier les ressources des VM ; peut modifier les frais du fournisseur |
Ressource |
API, MCP |
hosting:snapshots:view |
Consulter les instantanés du fournisseur et les dossiers d’instantanés sans modifier la VM |
Ressource |
API, MCP |
hosting:snapshots:create |
Créer des instantanés chez le fournisseur ; le stockage peut entraîner des frais |
Ressource |
API, MCP |
hosting:snapshots:delete |
Supprimer définitivement des instantanés du fournisseur |
Ressource |
API, MCP |
hosting:snapshots:restore |
Remplacer les données actuelles d’une VM par un instantané |
Ressource |
API, MCP |
hosting:snapshots:folders:manage |
Créer des dossiers d’instantanés et déplacer des instantanés entre dossiers |
Ressource |
API, MCP |
hosting:resources:delete |
Détruire les données d’une VM chez le fournisseur ou résilier une location HOSTKEY |
Ressource |
API, MCP |
hosting:resources:recover |
Redémarrer les démons Opfield ou relancer explicitement une installation en échec |
Ressource |
API, MCP |
hosting:billing:view |
Consulter le solde du compte, les frais, les factures et les transactions |
Ressource |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
housekeeping:view |
Consulter la configuration, les statistiques et l’historique d’exécution de la maintenance |
— |
API, MCP |
housekeeping:run |
Exécuter manuellement des tâches de maintenance |
— |
API, MCP |
housekeeping:configure |
Modifier la configuration et le calendrier de la maintenance |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
license:view |
Consulter l’état de la licence Opfield et le détail des droits |
— |
API, MCP |
license:manage |
Activer, mettre à jour ou supprimer la licence Opfield |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
ai:workspace:use |
Utiliser l’interface AI Workspace et l’assistant intégré |
— |
— |
feat:ai:use |
Utiliser Opfield Inference et consulter sa consommation d’inférence personnelle |
— |
API, MCP |
feat:ai:configure |
Configurer les paramètres et les fournisseurs d’IA |
— |
— |
ai:skills:manage |
Créer, modifier, activer, désactiver et supprimer des skills d’AI Workspace |
— |
— |
ai:sandbox:use |
Exécuter des tâches bornées dans des bacs à sable d’IA |
— |
— |
ai:sandbox:tier:medium |
Exécuter des tâches de bac à sable d’IA avec des limites de ressources moyennes |
— |
— |
ai:sandbox:tier:high |
Exécuter des tâches de bac à sable d’IA avec des limites de ressources élevées |
— |
— |
ai:sandbox:manage |
Consulter et tuer des tâches de bac à sable d’IA |
— |
— |
mcp:use |
Autoriser ce compte utilisateur à accéder au serveur MCP distant avec OAuth |
— |
— |
| Scope |
Description |
Restrictions |
Jetons |
inference:providers:view |
Consulter les fournisseurs d’inférence, les connexions, la découverte et les quotas |
— |
API, MCP |
inference:providers:manage |
Connecter, mettre à jour, synchroniser, router et déconnecter des fournisseurs d’inférence |
— |
API, MCP |
inference:models:manage |
Créer, publier, remplacer et supprimer des modèles d’inférence |
— |
API, MCP |
inference:limits:manage |
Configurer les budgets d’inférence par défaut et par utilisateur |
— |
API, MCP |
inference:usage:view |
Consulter la consommation d’inférence à l’échelle du système et par utilisateur |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
docker:containers:view |
Consulter les conteneurs Docker |
Ressource, Dossier |
API, MCP |
docker:containers:create |
Créer et dupliquer des conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:edit |
Modifier les paramètres et la configuration des conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:manage |
Démarrer, arrêter, redémarrer, tuer et recréer des conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:environment |
Modifier les variables d’environnement des conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:link |
Permettre à d’autres charges de travail de joindre un port d’un conteneur ou d’un déploiement via un lien entre conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:delete |
Supprimer des conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:console |
Ouvrir une console interactive dans les conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:files:read |
Parcourir et lire les fichiers des conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:files:write |
Créer, modifier, déplacer et supprimer des fichiers dans les conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:export |
Exporter des archives de conteneurs portables |
Ressource, Dossier |
API, MCP |
docker:containers:secrets |
Consulter et gérer les secrets chiffrés |
Ressource, Dossier |
API, MCP |
docker:containers:webhooks |
Consulter et gérer les déclencheurs de mise à jour par webhook des conteneurs |
Ressource, Dossier |
API, MCP |
docker:containers:mounts |
Ajouter, retirer ou modifier les montages des conteneurs et des déploiements, et donner une nouvelle image ou commande à une charge de travail dotée de montages de répertoires de l’hôte |
Ressource, Dossier |
API, MCP |
docker:containers:migrate |
Migrer des conteneurs et des déploiements entre nœuds Docker |
Ressource, Dossier |
API, MCP |
docker:availability:manage |
Activer, mettre à l’échelle, réparer et désactiver la Workload Availability multinœud |
Ressource, Dossier |
API, MCP |
docker:folders:manage |
Organiser en dossiers les conteneurs, déploiements, projets Compose, réseaux, volumes et images |
Dossier |
API, MCP |
Les journaux, statistiques, processus et l’inspection des conteneurs sont couverts par docker:containers:view ; il n’existe pas de scope distinct pour les journaux. La duplication d’un conteneur, et sa recréation avec des paramètres modifiés, nécessitent docker:containers:environment et docker:containers:secrets en plus de l’accès de création ou de gestion. La récupération de l’image lors de la création d’un conteneur ou d’un Deployment est couverte par docker:containers:create à la destination ; docker:images:pull n’est nécessaire que pour récupérer des images seules. Un lien vers une base de données ou un stockage sur un Deployment nécessite aussi docker:containers:manage sur celui-ci, car chaque modification de lien le redéploie, plus docker:containers:edit lorsque le lien modifie son environnement. docker:containers:manage autorise ensemble le démarrage, l’arrêt, le redémarrage, kill et la recréation ; il n’existe pas de scope limité au redémarrage. Ces scopes s’appliquent aussi aux conteneurs autonomes qu’Opfield a découverts sans les avoir créés. Voir Exploiter des charges de travail sans les adopter.
| Scope |
Description |
Restrictions |
Jetons |
docker:compose:view |
Découvrir et examiner les projets Compose, les services, la supervision, les journaux, les révisions et l’activité |
Ressource, Dossier |
API, MCP |
docker:compose:create |
Valider et déployer des projets Compose gérés ; l’adoption nécessite aussi Manage Compose Projects |
Ressource, Dossier |
API, MCP |
docker:compose:manage |
Adopter des projets et gérer le cycle de vie, les révisions, les secrets et les liaisons |
Ressource, Dossier |
API, MCP |
docker:compose:delete |
Supprimer des projets Compose ou exécuter des actions destructives de démontage ou de suppression des volumes |
Ressource, Dossier |
API, MCP |
Les projets Compose externes sont en lecture seule : docker:compose:view couvre leur inventaire, leur supervision et leurs journaux agrégés, tandis que les actions de cycle de vie ne deviennent disponibles qu’après l’adoption. Les conteneurs individuels qui appartiennent à un projet Compose ne peuvent pas être démarrés, arrêtés, redémarrés, modifiés ou supprimés via les scopes des conteneurs.
| Scope |
Description |
Restrictions |
Jetons |
docker:images:view |
Consulter les images Docker |
Ressource, Dossier |
API, MCP |
docker:images:pull |
Récupérer des images Docker |
Ressource, Dossier |
API, MCP |
docker:images:delete |
Supprimer et élaguer des images Docker |
Ressource, Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
docker:volumes:view |
Consulter les volumes Docker |
Ressource, Dossier |
API, MCP |
docker:volumes:create |
Créer des volumes Docker |
Ressource, Dossier |
API, MCP |
docker:volumes:edit |
Renommer, réétiqueter, redimensionner et adopter des volumes Docker |
Ressource, Dossier |
API, MCP |
docker:volumes:delete |
Supprimer des volumes Docker |
Ressource, Dossier |
API, MCP |
docker:volumes:export |
Exporter des archives de volumes Docker portables |
Ressource, Dossier |
API, MCP |
docker:volumes:files:read |
Parcourir, ouvrir et télécharger les fichiers des volumes Docker |
Ressource, Dossier |
API, MCP |
docker:volumes:files:write |
Créer, modifier, téléverser, déplacer et supprimer les fichiers des volumes Docker |
Ressource, Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
docker:networks:view |
Consulter les réseaux Docker |
Ressource, Dossier |
API, MCP |
docker:networks:create |
Créer des réseaux Docker |
Ressource, Dossier |
API, MCP |
docker:networks:edit |
Connecter et déconnecter des conteneurs |
Ressource, Dossier |
API, MCP |
docker:networks:delete |
Supprimer des réseaux Docker |
Ressource, Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
docker:registries:view |
Consulter les registres Docker |
— |
API, MCP |
docker:registries:create |
Ajouter des registres Docker |
— |
API, MCP |
docker:registries:edit |
Modifier les paramètres des registres Docker |
— |
API, MCP |
docker:registries:delete |
Supprimer des registres Docker |
— |
API, MCP |
docker:registries:internal:pull |
Ancien. Permet aux jetons d’API de l’utilisateur de récupérer ces dépôts sans accès aux charges de travail |
Ressource |
API, MCP |
docker:registries:internal:push |
Ancien. Permet aux jetons d’API de l’utilisateur d’envoyer vers ces dépôts sans accès aux charges de travail |
Ressource |
API, MCP |
L’accès d’un jeton d’API au registre interne est un paramètre du jeton lui-même (Internal registry), et non un scope. Le propriétaire peut accorder à un jeton la récupération (pull) lorsqu’il peut consulter une charge de travail ou une image Docker, et l’envoi (push) lorsqu’il peut modifier une charge de travail ; chaque requête est vérifiée par rapport aux permissions actuelles du propriétaire.
| Scope |
Description |
Restrictions |
Jetons |
docker:tasks |
Consulter l’avancement des tâches Docker |
Ressource |
API, MCP |
docker:tasks:manage |
Forcer l’annulation des tâches Docker actives |
Ressource |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
databases:view |
Consulter les connexions de bases de données enregistrées |
Ressource, Dossier |
API, MCP |
databases:create |
Créer des connexions de bases de données enregistrées |
Ressource, Dossier |
API, MCP |
databases:edit |
Modifier des connexions de bases de données enregistrées |
Ressource, Dossier |
API, MCP |
databases:bind |
Lier des conteneurs, des déploiements et des services Compose à des bases managées sans modifier la base ; la charge de travail nécessite aussi ses propres permissions |
Ressource, Dossier |
API, MCP |
databases:delete |
Supprimer des connexions de bases de données enregistrées |
Ressource, Dossier |
API, MCP |
databases:query:read |
Parcourir les tables et les clés, et exécuter des requêtes en lecture seule |
Ressource, Dossier |
API, MCP |
databases:query:write |
Insérer, mettre à jour, supprimer et exécuter des requêtes d’écriture sur les bases |
Ressource, Dossier |
API, MCP |
databases:query:admin |
Exécuter des commandes d’administration ou DDL sur les bases |
Ressource, Dossier |
API, MCP |
databases:credentials:reveal |
Afficher les identifiants et chaînes de connexion enregistrés des bases |
Ressource, Dossier |
API, MCP |
databases:folders:manage |
Créer, réordonner et supprimer des dossiers de bases de données |
Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
databases:backups:view |
Consulter les politiques de sauvegarde des bases et l’historique des exécutions |
Ressource, Dossier |
API, MCP |
databases:backups:manage |
Créer, modifier et supprimer des politiques de sauvegarde et supprimer l’historique des exécutions |
Ressource, Dossier |
API, MCP |
databases:backups:run |
Lancer et annuler des exécutions de sauvegarde |
Ressource, Dossier |
API, MCP |
databases:backups:restore |
Restaurer une sauvegarde dans une base cible nouvelle ou vide |
Ressource, Dossier |
API, MCP |
nodes:backups:execute |
Utiliser un nœud Storage comme exécuteur des tâches de sauvegarde et de restauration |
Ressource, Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
storage:view |
Consulter les connexions de stockage, le stockage managé et leur état |
Ressource, Dossier |
API, MCP |
storage:create |
Créer des connexions de stockage et du stockage managé |
Ressource, Dossier |
API, MCP |
storage:edit |
Modifier des connexions de stockage et du stockage managé, redémarrer ou relancer le provisionnement |
Ressource, Dossier |
API, MCP |
storage:delete |
Supprimer des connexions de stockage et du stockage managé |
Ressource, Dossier |
API, MCP |
storage:credentials:reveal |
Afficher les identifiants de stockage enregistrés |
Ressource, Dossier |
API, MCP |
storage:credentials:use |
Permettre aux sauvegardes et aux tâches de copie de stockage d’utiliser les identifiants de stockage enregistrés sans les afficher |
Ressource, Dossier |
API, MCP |
storage:iam |
Créer, révoquer, importer et geler des clés d’accès au stockage managé, et déplacer des liens de charges de travail entre clusters |
Ressource, Dossier |
API, MCP |
storage:bind |
Lier des conteneurs et des déploiements au stockage managé sans émettre de clés d’accès ; les permissions propres à la charge de travail sont aussi requises |
Ressource, Dossier |
API, MCP |
storage:objects:read |
Lister les buckets et les objets, lire les métadonnées, télécharger des objets et créer des liens de téléchargement |
Ressource, Dossier |
API, MCP |
storage:objects:write |
Téléverser des objets, créer des préfixes et supprimer des objets |
Ressource, Dossier |
API, MCP |
storage:objects:admin |
Créer et supprimer des buckets |
Ressource, Dossier |
API, MCP |
storage:folders:manage |
Créer, réordonner et supprimer des dossiers de stockage |
Dossier |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
notifications:alerts:view |
Consulter les règles d’alerte des notifications |
— |
API, MCP |
notifications:alerts:manage |
Créer, modifier et supprimer des règles d’alerte des notifications |
— |
API, MCP |
notifications:webhooks:view |
Consulter les webhooks de notification et leurs tentatives d’envoi |
— |
API, MCP |
notifications:webhooks:manage |
Créer, modifier, tester et supprimer des webhooks de notification |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Jetons |
logs:environments:view |
Consulter les environnements de journalisation externes |
Ressource, Dossier |
API, MCP |
logs:environments:create |
Créer des environnements de journalisation |
Ressource, Dossier |
API, MCP |
logs:environments:edit |
Modifier des environnements et des schémas de journalisation |
Ressource, Dossier |
API, MCP |
logs:environments:delete |
Supprimer des environnements de journalisation |
Ressource, Dossier |
API, MCP |
logs:environments:folders:manage |
Créer, réordonner et supprimer des dossiers d’environnements de journalisation |
Dossier |
API, MCP |
logs:tokens:view |
Consulter les jetons d’ingestion de journalisation |
Ressource, Dossier |
API, MCP |
logs:tokens:create |
Créer des jetons d’ingestion de journalisation |
Ressource, Dossier |
API, MCP |
logs:tokens:delete |
Révoquer des jetons d’ingestion de journalisation |
Ressource, Dossier |
API, MCP |
logs:schemas:view |
Consulter les schémas de journalisation réutilisables |
Ressource, Dossier |
API, MCP |
logs:schemas:create |
Créer des schémas de journalisation réutilisables |
Ressource, Dossier |
API, MCP |
logs:schemas:edit |
Modifier des schémas de journalisation réutilisables |
Ressource, Dossier |
API, MCP |
logs:schemas:delete |
Supprimer des schémas de journalisation réutilisables |
Ressource, Dossier |
API, MCP |
logs:schemas:folders:manage |
Créer, réordonner et supprimer des dossiers de schémas de journalisation |
Dossier |
API, MCP |
logs:read |
Rechercher et examiner les journaux externes |
Ressource, Dossier |
API, MCP |
Les scopes des jetons de journalisation et de recherche de journaux sont qualifiés par l’identifiant de l’environnement de journalisation ; leurs droits sur les dossiers se résolvent via les dossiers des environnements de journalisation.
| Scope |
Description |
Restrictions |
Jetons |
status-page:view |
Consulter la configuration de la page de statut, les services exposés, les incidents et l’aperçu |
— |
API, MCP |
status-page:manage |
Modifier les paramètres de la page de statut et les services exposés |
— |
API, MCP |
status-page:incidents:create |
Créer des incidents manuels et promouvoir des incidents automatiques |
— |
API, MCP |
status-page:incidents:update |
Modifier les détails des incidents et publier des mises à jour dans leur chronologie |
— |
API, MCP |
status-page:incidents:resolve |
Résoudre les incidents actifs de la page de statut |
— |
API, MCP |
status-page:incidents:delete |
Supprimer les incidents résolus de la page de statut |
— |
API, MCP |
