OpenFGA v1.21.0 est un modèle pour la question à laquelle la connexion ne répond jamais : ce technicien peut-il toucher l'objet de ce client ?

OpenFGA v1.21.0 est un modèle pour la question à laquelle la connexion ne répond jamais : ce technicien peut-il toucher l'objet de ce client ?

La réalité d'un MSP, ce sont de nombreux tenants clients, des techniciens qui ont des délégations différentes selon le client et des intégrations machine qui agissent seules. Après l'authentification, la vraie question est : « ce sujet peut-il effectuer cette action sur cet objet dans ce tenant ? » Un jeton, un claim de groupe ou un événement de déconnexion n'y répondent pas ; un point de décision, si. Le projet dont il est question ici est un modèle de référence, pas une recommandation : OpenFGA, dépôt openfga/openfga, Apache-2.0, projet CNCF Incubating depuis le 28 octobre 2025 (accepté le 14 septembre 2022), décrit par ses mainteneurs comme un moteur d'autorisation et de permissions à hautes performances inspiré de Google Zanzibar.

Le 5 octobre 2026, le dépôt GitHub affichait 5920 étoiles et un dernier push le 2 octobre 2026. La version v1.21.0, publiée le 20 septembre 2026, ne mentionne qu'un seul ajout, Dynamic Conditions, que le projet qualifie d'expérimental. Une version plus récente, la v1.22.0, a suivi le 6 octobre 2026. Cet article n'affirme pas qu'un produit Altovar utilise OpenFGA.

La suite de l'article explique comment l'autorisation fondée sur les relations s'applique à la multi-location d'un MSP, quelles preuves d'épinglage et de chaîne d'approvisionnement offrent les versions, ce qu'OpenFGA n'est pas (politique d'admission, overlay réseau, scanners) et six contrôles pour exploiter n'importe quel point de décision central. Connexion, déconnexion et validité du jeton sont des entrées ; le droit d'accès est une décision prise à chaque requête.

D'après la description et les topics du dépôt, OpenFGA est un moteur d'autorisation et de permissions inspiré de Google Zanzibar. Les topics citent le contrôle d'accès fondé sur les relations aux côtés de RBAC, d'ABAC et de l'accès fondé sur des politiques, ainsi que « entitlements ». Cet article s'en tient à ces sources : il ne propose ni matrice de fonctionnalités, ni chiffres de débit ou de latence, ni liste d'utilisateurs.

Le ReBAC à la manière de Zanzibar signifie, en langage d'acheteur, que les permissions découlent des relations entre sujets et objets (qui est membre de quel tenant, quel site appartient à quel tenant, quel technicien a une délégation sur quel site) plutôt que d'une longue liste de rôles copiée dans chaque jeton. La décision parcourt le graphe des relations. Elle ne colle pas un catalogue de rôles dans chaque JWT.

Gouvernance, selon la page du projet à la CNCF consultée le 5 octobre 2026 : accepté à la CNCF le 14 septembre 2022, Incubating depuis le 28 octobre 2025. Incubating est un niveau de maturité dans un processus de fondation. Ce n'est ni une certification de sécurité ni un contrat de support. Un MSP qui traite « CNCF Incubating » comme « audité pour nos clients » lit une étiquette de fondation comme une garantie client qu'elle n'apporte pas.

Le 5 octobre 2026, le dépôt comptait 5920 étoiles GitHub et 511 forks. Les étoiles sont un signal de popularité, pas une évaluation. La page de la CNCF affiche des métriques LFX distinctes avec un autre nombre d'étoiles ; cet article utilise le chiffre GitHub et ne mélange pas les deux. La licence déclarée dans le dépôt est Apache-2.0.

Les versions récentes : v1.22.0 le 6 octobre 2026, v1.21.0 le 20 septembre 2026, v1.20.0 le 8 septembre 2026 et v1.19.0 le 25 août 2026. Aucune n'est marquée comme préversion. La règle d'épinglage à retenir : exécuter la v1.21.0 ou une version ultérieure, et rien de plus ancien, la v1.22.0 étant la meilleure cible pour les nouveaux déploiements parce qu'elle ajoute une mise à jour de sécurité d'une dépendance. Ne suivez pas une image latest flottante dans un environnement client sans un ticket de changement qui nomme le tag.

Le plancher n'est pas simplement « la plus récente ». La v1.20.0 comportait une section Security : un correctif de CVE dans la chaîne d'outils, une dépendance de sonde de santé reconstruite et le correctif d'un avis de sécurité OpenFGA dans le chemin ListUsers. Tout ce qui est antérieur à la v1.20.0 n'a pas ces correctifs ; la v1.21.0 s'appuie dessus. La v1.22.0 ajoute une autre entrée Security : une bibliothèque gRPC mise à jour qui corrige GO-2026-6443. La phrase qu'un MSP peut mettre dans un ticket est : « la v1.20.0 a apporté des correctifs de sécurité, dont un avis OpenFGA dans le chemin ListUsers ; exécuter ≥ v1.21.0, de préférence v1.22.0. »

Dynamic Conditions exige une formulation précise. Les notes de la v1.21.0 la présentent comme « une nouvelle fonctionnalité expérimentale » (notre traduction) : expérimentale, pas en disponibilité générale. La logique des droits des clients ne devrait pas dépendre d'une fonctionnalité expérimentale, sauf si le client accepte explicitement ce risque par écrit.

Les preuves de version qu'un MSP peut joindre à un ticket de changement, telles qu'elles figurent sur les versions v1.21.0 et v1.22.0 : les deux sont marquées immuables, et chacune fournit des fichiers de sommes de contrôle signés, une attestation in-toto et un SBOM par archive binaire. Ces preuves étayent le fait que l'artefact déployé correspond à ce que le projet a publié et que vous disposez d'une liste de composants. Ce n'est pas un audit du code ni de votre modèle d'autorisation.

La question, écrite une fois et réutilisée : sujet · action · objet · tenant. Un technicien, un compte partenaire, un utilisateur client et une intégration machine sont quatre types de sujets. « Lire », « modifier », « exporter » et « supprimer » sont des actions différentes. Un appareil, une boîte aux lettres, un jeu de sauvegardes sont des objets. Chaque objet appartient à exactement un tenant client. C'est à cette question en quatre parties qu'un événement de connexion ne répond jamais à lui seul.

Des relations plutôt que des rôles copiés : un tenant contient des sites ou des organisations ; les ressources appartiennent à un site ; un technicien est lié à un site par une délégation qui peut être limitée dans le temps ; un administrateur client n'est lié qu'à son propre tenant. Le point de décision déduit « ce technicien peut-il modifier cette boîte aux lettres ? » en parcourant ces relations.

Pourquoi cela aide le MSP : le droit d'accès quitte le jeton et les milliers de vérifications if dispersées dans le code applicatif pour devenir un seul endroit que l'on peut inspecter, tester et journaliser. Révoquer la délégation d'un technicien pour un client revient à supprimer une relation, pas à réémettre des jetons dans chaque application. Le changement a un responsable et une piste d'audit dans un seul magasin.

Le cadre défensif : refus par défaut, moindre privilège et une vérification à chaque requête (OWASP Authorization Cheat Sheet). Le contrôle d'accès défaillant (broken access control), y compris l'accès aux objets d'un autre tenant, est la classe de défaillance que ce modèle vise à réduire. Une déconnexion ou un signal de révocation peut déclencher une nouvelle vérification ; le point de décision est l'endroit où elle a lieu. C'est aussi pourquoi une déconnexion, à elle seule, n'est pas une révocation au niveau du tenant.

Gatekeeper et Kyverno sont des politiques d'admission Kubernetes pour les objets d'infrastructure. Ils décident si un manifeste peut entrer dans un cluster, pas si un technicien peut lire la boîte aux lettres d'un client. Aucun ne remplace l'autre. Un MSP qui confond politique d'admission et droits applicatifs placera le mauvais contrôle dans la mauvaise couche.

OpenZiti est un overlay réseau zero trust. Il décide quelles identités peuvent atteindre quels services sur le réseau ; il ne décide pas des droits applicatifs objet par objet. Accessibilité réseau et permission sur l'objet sont des portes différentes.

Trivy, Syft et DefectDojo sont des scanners, des générateurs de SBOM et des outils d'agrégation de résultats. Ils décrivent ce que contient votre logiciel et ce qui ne va pas. Ils n'autorisent pas de requêtes.

Cet article ne dit pas qu'Auris, ou un autre produit Altovar, utilise, intègre ou embarque OpenFGA. OpenFGA est cité comme modèle de référence open source pour l'autorisation centralisée.

Six contrôles défensifs pour exploiter n'importe quel point de décision central, chacun avec ce qui vaut preuve et ce qui n'en est pas une.

Premièrement, l'inventaire : quels magasins et modèles d'autorisation existent, par client ou partagés, et qui peut les modifier. La preuve est une liste exportée et un responsable par modèle. « Nous utilisons ReBAC » n'est pas une preuve. Deuxièmement, l'épinglage : ≥ v1.21.0 consigné dans le ticket de changement, avec le résultat de la vérification des sommes de contrôle et de l'attestation en pièce jointe. Un nombre d'étoiles ou un tag latest n'est pas une preuve.

Troisièmement, protéger l'API de décision elle-même : uniquement des appelants authentifiés, accessible seulement depuis la couche applicative, opérations d'administration limitées à des opérateurs nommés avec MFA. Quatrièmement, les modifications du modèle sont des modifications de code : relues, versionnées et testées avant le déploiement avec des cas explicites de refus entre tenants. La preuve est un test qui montre que le tenant B ne peut pas atteindre l'objet du tenant A. « Le modèle compile » n'est pas une preuve.

Cinquièmement, sauvegarder et restaurer les données de relations ; répéter une restauration. Un point de décision qui a perdu ses relations échoue soit en mode ouvert, soit en mode fermé, et les deux sont des pannes. Sixièmement, journaliser les décisions et les modifications du modèle dans le SIEM comme signaux opérationnels, par exemple des modifications inattendues du modèle ou des pics de refus après une version. Enfin, tenir les fonctionnalités expérimentales à l'écart des chemins de droits des clients jusqu'à ce que le projet les classe autrement.

En bref : Apache-2.0 ; CNCF Incubating depuis le 28 octobre 2025 ; 5920 étoiles GitHub le 5 octobre 2026 ; version plancher v1.21.0 (20 septembre 2026), la v1.22.0 (6 octobre 2026) étant la meilleure cible ; les correctifs de sécurité de la v1.20.0 sont en dessous ; Dynamic Conditions est expérimental. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft et DefectDojo ne remplacent pas un point de décision applicatif central. Connexion, déconnexion et validité du jeton sont des entrées ; le droit d'accès est une décision prise à chaque requête.

Cet article n'affirme pas qu'Auris utilise OpenFGA. Le modèle est une architecture de référence open source pour la question du MSP à laquelle l'authentification, à elle seule, ne répond jamais.