Associer les groupes SSO aux rôles, depuis l'application​

Quel groupe SSO accorde quel rôle sur quels projets était une valeur du chart — auth.oidc.mapping dans values.yaml, un helm upgrade par changement — si bien qu'ouvrir l'accès à une équipe exigeait un déploiement. Paramètres → Accès affiche désormais ces règles et permet à un administrateur d'en ajouter, d'en modifier et d'en supprimer d'autres à côté.

• Le chart reste la base déclarée. Ses règles s'affichent en lecture seule et, en cas de collision de nom, le chart l'emporte : une règle créée dans l'application pour un groupe que le chart déclare aussi est conservée et marquée comme éclipsée, avec la raison sur sa ligne, au lieu d'être ignorée en silence ou refusée d'emblée.
• Un changement s'applique à la prochaine connexion du groupe ou au prochain rafraîchissement de jeton, et atteint chaque réplique du hub en une quinzaine de secondes. Cette borne est affichée dans le panneau, pour qu'une lecture encore ancienne sur une autre réplique juste après un enregistrement ne soit pas prise pour un échec.
• Réinitialiser supprime toutes les règles créées dans l'application et ramène l'installation exactement à ce que le chart déclare. Une installation sans fournisseur d'identité configuré ne voit jamais le panneau — il n'y a rien à associer.

Jetons d'API personnels​

L'API du hub a vocation à dépasser le navigateur — une source de données Grafana et une CLI sont sur la feuille de route — mais la seule accréditation était un cookie de session. Paramètres → Accès émet désormais des jetons d'API personnels : créez-en un, avec une expiration optionnelle, copiez-le une seule fois, et envoyez-le en Authorization: Bearer avurut_….

• Montré une fois, haché pour toujours. Seul le SHA-256 d'un jeton est stocké ; la valeur brute n'apparaît qu'une seule fois, à la création. Le préfixe avurut_ dit quel type d'accréditation a fui si l'une d'elles apparaît un jour dans un log.
• Un jeton, c'est son propriétaire, en direct. Il ne porte aucune permission propre — chaque requête est résolue vers les rôles et droits par projet actuels du propriétaire : désactiver un utilisateur désactive tous ses jetons, par construction et non par nettoyage.
• Aucune rétrogradation silencieuse. Un jeton invalide ou expiré est un 401 net, jamais un repli vers le lecteur anonyme qu'une installation peut avoir activé.
• La révocation est immédiate et en libre-service ; un administrateur global peut lister et révoquer ceux de n'importe qui. La liste montre la dernière utilisation de chaque jeton : une accréditation dormante se voit avant de devenir un problème.

• Activer et couper les signaux depuis l'interface. Paramètres → Collecte est devenu éditable : activez ou coupez les traces OBI, les logs, les métriques d'infrastructure, le profilage ou la collecte d'énergie, modifiez les espaces de noms exclus, et le capteur suit en quelques secondes — sans helm upgrade. Désactivé par défaut ; l'activer n'accorde au hub qu'un rôle étroit sur ses propres ConfigMaps de capteur et son DaemonSet, rien d'autre, et le chemin d'écriture est prouvé de bout en bout contre un vrai cluster en CI.

• Dire quels services comptent, depuis l'application. Les groupes de santé s'écrivent dans Paramètres → Groupes — nom, niveau de criticité, espaces de noms ou services couverts — et s'appliquent dès la lecture de santé suivante. Les groupes déclarés dans le chart restent en lecture seule et l'emportent en cas de collision de nom ; le regroupement automatique par espace de noms est inchangé, rien ne disparaît pendant que vous organisez.

• Un seul écran pour l'état du parc. Le Tableau de bord est la page d'accueil : santé des groupes de services, topologie vivante à côté des alertes actives, et capacité Kubernetes, en trois bandes. Chaque bande suit son module — une bande dont le module est coupé ne se monte simplement pas — et sans santé des services, la synthèse se rabat sur les services les plus actifs plutôt que d'inventer un second modèle de statut.

• La carte des services dit ce qui ne va pas, pas seulement que quelque chose ne va pas. Les anneaux des nœuds affichent désormais le statut réel du service, lu depuis la même consolidation que le tableau Santé des services ; les arêtes portent le p50/p95 côté appelant réellement coûté par ce chemin d'appel ; survoler un nœud focalise son voisinage ; et la recherche, le filtre « problèmes seulement » et le filtre de groupe vivent dans l'URL — une carte réduite est un lien. La loupe carbone est devenue un halo : santé et gCO2e sont visibles en même temps.

• Accorder les accès depuis l'application. Le mapping OIDC groupe→rôle s'édite désormais dans Paramètres → Accès — les règles du chart restent la référence et une règle éclipsée dit pourquoi — et le même onglet émet des jetons d'API personnels : hachés au repos, montrés une seule fois, résolus à chaque requête vers les permissions vivantes de leur propriétaire, si bien que désactiver un utilisateur désactive tous ses jetons.

• Où vivent les données, et qui peut y toucher. Paramètres → Stockage et Paramètres → Accès : la connexion ClickHouse en lecture seule avec l'occupation par signal et la rétention confrontée au TTL que les tables appliquent vraiment, et une matrice de permissions que le hub déduit de ses propres gardes de routes — elle ne peut pas diverger de ce qui est appliqué.

• Trouver un pod sur l'écran Nœuds. Les deux tables se trient sur chaque colonne et se filtrent par nom, espace de noms ou charge de travail ; les filtres vivent dans l'URL et les compteurs affichent « N sur M » — une table réduite ne peut pas être prise pour un cluster qui rétrécit.

Sécurité​

• Trois points d'API green répondaient sans authentification. GET /api/v1/green/summary, /green/budgets et /green/report étaient enregistrés sans le middleware de session : une installation avec l'authentification activée servait l'énergie et le carbone de n'importe quel projet à un appelant non authentifié. Les trois exigent désormais le rôle lecteur et respectent les droits par projet, et un test couvre l'ensemble des routes de données de projet. Détails dans la note de sécurité.

Corrigé​

• Le compte de démo partagé se voyait proposer un formulaire de mot de passe qu'il ne pouvait jamais soumettre. Le hub avait raison de refuser le changement — l'identifiant de démo est partagé et régénéré à chaque démarrage — mais l'interface n'en savait rien. /api/v1/auth/me indique désormais si la rotation en libre-service s'applique et sinon pourquoi, et l'onglet Compte affiche l'explication au lieu du formulaire.

La mise à niveau depuis v0.4.x est un helm upgrade normal. Les migrations de schéma 0016 à 0018 s'appliquent automatiquement (hub.autoMigrate). Voir la page Versions et la release GitHub.

• Un anneau de santé, pas un point d'erreur. L'anneau d'un nœud reflète sa vraie santé — healthy, degraded, down ou idle — lue directement dans la même consolidation sensible aux dépendances que l'écran Santé des services. La carte ne recalcule plus ses propres seuils : les deux écrans ne peuvent donc plus se contredire. Un service que la consolidation ne couvre pas s'affiche unknown, jamais healthy.

• Une vraie latence par arête. Chaque arête porte désormais un p50 et un p95 mesurés du côté de l'appelant — ce que cet appel a réellement coûté, réseau et attente compris. C'est volontairement différent du p95 que le nœud affiche pour son propre travail côté serveur, et l'écart entre les deux est souvent l'information utile : dans les données de démonstration, le nœud affiche p95 200ms tandis que l'arête qui y entre affiche p95 220ms — 20ms que l'appelant a payés et que l'appelé n'a jamais vus. Les arêtes issues des flux réseau, et non de spans, omettent simplement le champ plutôt que d'afficher un faux zéro.

• Le survol recentre le regard. Survoler un nœud estompe tout ce qui est hors de son voisinage, épaissit ses arêtes, et étiquette chacune avec son rpm, son p95, son taux d'erreur et son RTT TCP quand il est mesuré — une flèche à mi-arête indique le sens sans avoir à suivre le trait.

• Filtres et contrôles, tout dans l'URL. Une recherche par nom, une case « problèmes seulement » et un filtre par groupe de services — chacun atterrit dans la chaîne de requête, si bien qu'une carte restreinte devient un lien à coller à un collègue plutôt qu'un écran à décrire. Zoom, ajustement à la vue, nouvelle disposition et une légende complètent l'ensemble. Les filtres de statut et de groupe n'apparaissent que si la santé des services tourne, puisque tous deux lisent sa consolidation.

• Le carbone est passé sur un halo. L'anneau était jusqu'ici la seule bordure d'un nœud ; la vision carbone dessine désormais son gCO2e en un halo doux autour du nœud — qui peut ainsi montrer à la fois son anneau de santé et son halo carbone.

• La carte compacte du Tableau de bord en profite aussi. La topologie compacte du Tableau de bord affiche le même composant : elle hérite des anneaux et du survol focalisé sans effort, avec les données de santé que le Tableau de bord récupérait déjà.

Un écran, trois réponses​

• Mes services sont-ils en bonne santé ? Une carte par groupe de services — les groupes que vous avez créés dans Paramètres → Groupes — avec son niveau de criticité, son état, et le débit, la latence et le taux d'erreur qui fondent cet état. Les pires états passent en tête : un groupe en difficulté n'est jamais celui qui déborde en fin de rangée.

• Qui parle à qui, et quelque chose se déclenche-t-il ? La carte des services à l'échelle d'une vue d'ensemble, à côté de tout ce qui alerte en ce moment. Ce n'est pas une capture de la carte : c'est le même graphe, donc un service rouge ici l'est aussi là-bas.

• Le cluster est-il sous tension ? Nœuds, pods, namespaces et charges de travail en un coup d'œil, plus l'utilisation mémoire par nœud, les plus chargés en premier.

Chaque carte est un lien vers l'écran qui l'explique. Le Tableau de bord est là où l'on remarque ; les écrans existants sont là où l'on enquête.

Il fonctionne sur l'installation que vous exploitez vraiment​

Chaque bande dépend d'un module, et une bande dont le module est désactivé n'est tout simplement pas là — l'écran ne présente jamais un panneau qu'il ne peut pas remplir, et n'appelle jamais une API que votre installation ne fait pas tourner. Désactivez la santé des services et la première bande se rabat sur vos services les plus actifs plutôt que de disparaître. N'exécutez que le cœur, et le Tableau de bord s'ouvre quand même, avec la carte et vos services.

Ces cartes de repli ne portent délibérément aucun état de santé. Les seuils et la propagation des dépendances critiques appartiennent au module de santé des services ; en inventer un second jeu pour cet écran reviendrait à afficher deux réponses différentes à la même question.

Ce que la capacité affirme, et ce qu'elle n'affirme pas​

La bande de capacité rapporte ce que le sensor mesure. La mémoire affiche une vraie barre d'utilisation, parce que ses deux moitiés — utilisée et disponible — sont collectées.

Le CPU est indiqué en cœurs utilisés, pas en pourcentage, faute d'une capacité de nœud par laquelle diviser : les métriques de nœud viennent du kubelet, qui ne publie pas le CPU allouable. Un pourcentage aurait dû inventer son propre dénominateur, et une lecture de capacité à laquelle on ne peut pas se fier vaut moins qu'une valeur absolue honnête. Chaque barre porte son chiffre autant que sa couleur : rien sur cet écran ne se lit à la teinte seule.

Voir l'état des fonctionnalités pour situer le Tableau de bord parmi les autres écrans.

• La collecte devient un réglage, plus un déploiement. Réglages → Collecte active ou coupe les traces eBPF, les logs, les métriques d'infrastructure, le profilage et la mesure d'énergie, et modifie la liste des espaces de noms exclus. Coupez le profilage à 2 h du matin parce qu'il vous coûte plus qu'il ne vous apprend, et rallumez-le au matin — sans toucher au chart.

• Ce que l'écran affiche est ce que le capteur fait vraiment. Il présente la configuration effective : les valeurs de votre chart avec votre surcharge appliquée, et non l'une ou l'autre. « Réinitialiser » efface la surcharge et ramène le cluster exactement à ce que déclare le chart — une réinitialisation qui se contenterait d'oublier le réglage laisserait les deux en désaccord silencieux.

• Désactivé par défaut, et étroit une fois activé. La fonctionnalité dépend de collection.runtimeControl.enabled. L'activer autorise le hub à mettre à jour ses quatre ConfigMaps de capteur nommées et à modifier son DaemonSet de capteur nommé, dans son propre espace de noms — rien à l'échelle du cluster, rien qui appartienne à autrui. Le hub redéploie le capteur via sa propre annotation et laisse intacte celle du chart : un helm upgrade ultérieur se comporte donc comme avant. Option désactivée, rien ne change et aucun droit supplémentaire n'est accordé.

• Vérifié sur un vrai cluster, pas sur une simulation. Le test d'installation Helm installe désormais la fonctionnalité activée, écrit un réglage via l'API et vérifie qu'il atteint la configuration du capteur et redéploie le DaemonSet — puis réinitialise et vérifie que le cluster revient en arrière. Un réglage enregistré mais qui n'atteint jamais le capteur est précisément la panne qui compte ici, et ce test est fait pour l'attraper.

La configuration se trouve dans le chart sous collection.runtimeControl. Voir l'installation Kubernetes pour l'option, et les modules pour la façon dont chaque signal est activé.

Ce qui était exposé​

Pour n'importe quel projet nommé dans l'en-tête de la requête, sans connexion :

• l'énergie par service en wattheures et le carbone en gCO2e,
• l'utilisation des budgets carbone mensuels,
• l'export de rapport prêt pour la CSRD.

Ces routes sont en lecture seule : rien ne pouvait être modifié par ce biais. Mais la donnée dessine assez fidèlement ce que fait tourner un parc et à quelle intensité — noms de services, charge relative, et la forme d'une activité dans le temps.

Rien d'autre n'était concerné : toutes les autres routes de signal — traces, logs, métriques, carte des services, santé, alerting, suivi des erreurs, infrastructure — passaient déjà par l'intergiciel de session et appliquaient les droits par projet.

Pourquoi​

Ces routes étaient câblées avec l'enveloppe de gestionnaire nue plutôt qu'avec celle qui garde l'accès : aucune identité n'était donc jamais attachée à la requête. Le contrôle de portée par projet interprète alors « pas d'identité » comme « l'authentification est désactivée » — la branche qui existe pour qu'une installation en auth.enabled=false continue de fonctionner — et laissait passer la requête.

Suis-je concerné ?​

Oui si toutes ces conditions sont réunies :

• le module green est activé (il est désactivé par défaut : une installation qui ne l'a jamais allumé n'a jamais été exposée),
• l'authentification est activée, et
• l'API du hub est joignable par quelqu'un à qui vous ne donneriez pas le rôle lecteur.

Une installation dont le hub n'est joignable qu'à l'intérieur du cluster n'était pas exposée à quelqu'un qui n'atteignait pas déjà bien davantage.

Le correctif​

Les trois routes exigent désormais le rôle lecteur et respectent les droits par projet, exactement comme tous les autres signaux. Mettez à jour vers une version contenant ce changement.

Un test vérifie maintenant que toutes les routes de données de projet répondent 401 sans session, au lieu de les contrôler une par une : la faille avait survécu parce que rien n'avait jamais vérifié l'ensemble d'un seul tenant. Elle a été trouvée en indexant la garde de chaque route pour construire une vue des permissions dans les Paramètres — la même idée appliquée au produit : déduire les règles de ce que le serveur applique, plutôt que de les écrire deux fois.

• Un tri sur chaque colonne. Les nœuds par nom, processeur, mémoire, réseau ou nombre de pods ; les pods par nom, espace de noms, charge de travail, nœud, processeur ou mémoire. Les nœuds restent par défaut dans l'ordre alphabétique, pour que la liste ne se réorganise pas d'un rafraîchissement à l'autre, et le classement par charge n'est qu'à un clic. Le réseau se trie sur l'émission et la réception cumulées — trier sur la seule réception ferait passer pour calme un nœud qui émet beaucoup.

• Un filtre à la frappe. Les nœuds par nom ; les pods par nom, espace de noms ou charge de travail, avec un sélecteur d'espace de noms qui apparaît dès qu'il y a plus d'un choix possible. Rien n'attend une requête : les lignes sont déjà dans le navigateur.

• Une vue filtrée est un lien. Le filtre vit dans l'URL, comme partout ailleurs ici : vous envoyez à un collègue le tableau exact que vous avez sous les yeux au lieu de le décrire.

• Des compteurs qui ne trompent pas. Filtre actif, l'en-tête indique « N sur M » : un tableau restreint ne se confond jamais avec un cluster qui rétrécit. Et un filtre sans résultat le dit — au lieu d'afficher le message « installez le capteur pour collecter les métriques », qui vous enverrait diagnostiquer une installation en parfaite santé.

Voir les métriques d'infrastructure pour ce que l'écran Nœuds collecte, et comment.

• Paramètres → Groupes. Créez un groupe à partir d'un nom, d'un niveau de criticité (T0–T3) et des espaces de noms ou services qu'il couvre ; modifiez-le ou supprimez-le ensuite. Le changement s'applique à la lecture de santé suivante — sans redémarrage, sans redéploiement, sans pull request. L'écran Santé des services renvoie directement vers l'éditeur au lieu de citer une clé de configuration.

• Le regroupement automatique fonctionne toujours. Les services qu'aucun groupe ne revendique continuent d'être rassemblés par espace de noms au niveau par défaut, exactement comme avant : rien ne disparaît pendant que vous organisez.

• Les groupes déclarés dans le chart continuent de fonctionner, et l'emportent. Ils s'affichent en lecture seule, car une installation qui gère ses groupes dans Git ne doit pas les voir écrasés discrètement depuis un navigateur. Le conflit est refusé au moment de l'enregistrement plutôt que découvert à la mise à jour suivante — et si le chart revendique plus tard un nom que vous aviez déjà créé, ce groupe est signalé comme remplacé au lieu de cesser silencieusement de regrouper quoi que ce soit.

• L'alerting et l'écran ne peuvent plus diverger. Les deux sources sont fusionnées à un seul endroit, partagé par l'API de santé et l'évaluateur d'alertes. C'est ce qui compte : l'évaluateur ne passe pas par l'API, donc fusionner ailleurs aurait signifié qu'un groupe créé par vos soins s'affiche comme critique à l'écran sans jamais déclencher la moindre alerte. Un test parcourt les deux chemins puis déclenche une vraie règle sur un groupe qui n'existe qu'en base.

• Sûr par construction. Les écritures sont réservées aux administrateurs et validées avec les mêmes règles que la configuration du chart au démarrage : rien de ce que vous enregistrez ici ne fera échouer le prochain démarrage du hub. Tous les autres peuvent lire les définitions — voir comment le parc est organisé n'est pas un privilège.

Les seuils, les arêtes critiques et le niveau par défaut restent pour l'instant dans serviceGroups ; les groupes sont la partie dont on a besoin au quotidien.

Stockage​

• La connexion, en lecture seule. Adresse, base et utilisateur du ClickHouse auquel ce hub parle. La lecture seule est la réponse honnête, pas une fonctionnalité manquante : ClickHouse est le magasin de données, il ne peut donc pas contenir sa propre chaîne de connexion. La carte le dit et vous donne la ligne --set, au lieu d'un formulaire qui échouerait en silence. Elle s'affiche même quand ClickHouse est injoignable — le moment précis où « quelle adresse n'a-t-on pas réussi à joindre ? » est la première question.

• L'occupation par signal, déplacée depuis l'onglet État : taille sur disque, taux de compression, nombre de lignes, ancienneté des données. Chaque onglet répond maintenant à une seule question — État, c'est est-ce que ça va bien en ce moment ; Stockage, c'est qu'y a-t-il dedans.

• Une rétention à laquelle se fier. Le nombre de jours dans vos valeurs est ce que l'installation est configurée pour conserver. Le TTL des tables est ce que ClickHouse applique réellement — et modifier une valeur de rétention ne change rien aux tables déjà créées tant que la migration ne réapplique pas le TTL. D'ici là, le nombre configuré est un vœu. Quand les deux divergent, la colonne affiche 30j → 7j plutôt que de répéter le vœu, et une base dont la rétention n'a pas encore été appliquée affiche → aucune.

Accès​

Quel rôle peut lire, et lequel peut modifier, chaque domaine du produit — carte des services, traces, suivi des erreurs, alerting, utilisateurs, et le reste.

Chaque case vient du hub, qui la déduit des autorisations avec lesquelles ses routes sont réellement enregistrées. Rien n'est recopié dans le navigateur : ajoutez un point d'API réservé aux administrateurs et il apparaît ici ; changez ce qu'une route exige et ce tableau change avec elle. Un tableau de permissions qui peut contredire ce que le serveur applique est pire que pas de tableau du tout, parce qu'on le croit.

Une installation qui tourne sans authentification l'annonce en haut de l'onglet, au lieu de présenter un modèle que rien n'applique.

Ce que cela a permis de trouver​

Construire cette matrice a exigé d'indexer la garde de chaque route — c'est ainsi que l'on a vu que trois d'entre elles n'en avaient aucune. Voir la note de sécurité : si vous utilisez le module green avec l'authentification activée, elle vaut deux minutes de votre temps.

• Les utilisateurs, gérés de bout en bout. Réglages → Utilisateurs permet désormais de modifier le nom et les rôles d'un utilisateur, de réinitialiser son mot de passe et de le supprimer — une seconde étape explicite, accessible seulement après désactivation, pour qu'une suppression ne tienne jamais à un clic malheureux. Un nouvel onglet Réglages → Compte permet à tout utilisateur local connecté de changer son propre mot de passe : le mot de passe actuel est exigé, les autres sessions sont fermées, et celle que vous utilisez reste ouverte. Ces opérations sont refusées aux utilisateurs SSO, dont l'identifiant appartient au fournisseur d'identité.

• Un administrateur pouvait créer un mot de passe local fonctionnel sur un compte SSO. PUT /api/v1/users/{id} acceptait un mot de passe pour n'importe quel utilisateur, quelle que soit son origine, et le chemin de connexion ne filtrait pas davantage sur cette origine — le nouvel identifiant constituait donc une véritable connexion, contournant le fournisseur d'identité ainsi que son MFA et sa politique d'accès conditionnel. La modification de mot de passe est désormais réservée aux comptes locaux, aussi bien sur la route d'administration que sur la nouvelle route en libre-service.

• Changer d'adresse IP suffisait à contourner le verrouillage des connexions. Les deux axes de limitation portaient sur l'adresse du client : des tentatives réparties sur N adresses offraient N × 5 essais par minute contre un même compte sans déclencher ni l'un ni l'autre — un simple pool NAT cloud rendait le verrouillage par compte décoratif. Un troisième axe compte désormais les échecs sur le compte lui-même (20 par minute), aussi bien pour la connexion que pour le changement de mot de passe en libre-service. C'est un arbitrage assumé : des échecs répétés maintiendront la connexion à ce compte bloquée sur une fenêtre d'une minute qui se réinitialise seule, sans jamais toucher aux sessions déjà ouvertes ni aux connexions réussies.

• Une connexion SSO pouvait s'approprier l'adresse e-mail d'un compte local. Un utilisateur du fournisseur d'identité dont l'e-mail correspondait à un compte local ajoutait une seconde ligne partageant cette adresse, et la recherche par mot de passe retenait ensuite indifféremment l'une ou l'autre — quiconque pouvait fixer sa propre revendication d'e-mail pouvait donc viser l'administrateur d'amorçage. La recherche donne maintenant la priorité au compte local, et la connexion par mot de passe est réservée aux comptes locaux, au lieu de compter sur le fait que les lignes SSO portent une empreinte de mot de passe vide.

• Une installation dont la migration de schéma n'a jamais tourné se répare d'elle-même. Le schéma est appliqué par un hook Helm post-install/post-upgrade — que Helm n'exécute qu'après le succès de --wait. Une release qui expirait sur un composant lent ne créait donc jamais le job, alors que les déploiements déjà appliqués par Helm, eux, démarraient normalement. Le résultat avait l'air en bonne santé et répondait table inconnue à tout. Le hub vérifie désormais son schéma à la connexion et applique lui-même ce qui manque (hub.autoMigrate, actif par défaut ; les migrations sont idempotentes). Quand il ne le peut pas — pas de droits DDL, ou auto-réparation désactivée — il émet une seule erreur nommant le remède au lieu d'un flot d'avertissements, et Réglages → État gagne un composant Schéma indiquant l'état appliqué face à l'état attendu.

• Un nom de base ClickHouse autre que celui par défaut ne casse plus silencieusement l'installation. clickhouse.external.database est une valeur documentée et validée, mais chaque migration codait en dur le préfixe otel : les tables atterrissaient dans une base pendant que le hub interrogeait l'autre et la trouvait vide. Les migrations nomment désormais leur base via un paramètre substitué, et le nom configuré est validé comme identifiant au démarrage. Les installations sur la base par défaut ne sont pas concernées.

• Green ne fait plus tomber la sonde sur les nœuds sans RAPL. La source de mesure s'arrête au démarrage lorsqu'elle ne trouve aucune zone powercap, et un conteneur qui s'interrompt lui-même empêche tout le pod de passer Ready : activer la collecte green sur une flotte de VM emportait donc les logs, les traces et les métriques avec un signal énergétique pourtant optionnel. La source mesurée peut maintenant être retirée seule via sensor.green.kepler.enabled=false, l'estimation TDP continuant d'alimenter la page Green. Le matériel doté de RAPL n'est pas concerné.

• Se connecter derrière un reverse proxy qui réécrit Host ne renvoie plus 403. La vérification CSRF comparait l'Origin du navigateur au Host reçu par le hub : un proxy transmettant au cluster son adresse d'ingress transformait toute écriture — à commencer par le POST de connexion — en requête inter-origine rejetée. auth.trustedOrigins déclare les origines légitimes malgré un Host différent, et auth.originCheck (enforce | log | off) abaisse le contrôle lorsqu'on ne peut pas les énumérer ; log autorise l'écriture et enregistre le couple Origin/Host, ce qui permet justement de découvrir ce que votre proxy envoie réellement. Le comportement par défaut reste strict, et une publicUrl OIDC est approuvée automatiquement.

La montée depuis une v0.3.x est un helm upgrade ordinaire. La migration de schéma 0015 s'applique automatiquement. Si vous utilisez un compte ClickHouse durci sans droits DDL, conservez le job de migration tel quel et laissez hub.autoMigrate actif : il signalera proprement au lieu d'échouer. Voir la page Versions et la release GitHub.

• Des projets que vous administrez. Créez, renommez et supprimez vos projets dans Paramètres → Général ; le sélecteur et l'onglet Général suivent immédiatement, tandis que le projet natif default et tout projet déclaré dans le chart restent en lecture seule et clairement identifiés. L'identifiant d'un projet est un slug de tenant immuable — seul son nom d'affichage est modifiable : aucune télémétrie n'est jamais réécrite ni perdue.
• Une télémétrie qui prouve son origine. Émettez des clés d'API d'ingestion par projet ; le secret en clair n'est affiché qu'une seule fois et seule son empreinte est stockée. Les clés sont validées dans la passerelle — le hub n'entre jamais dans le chemin des octets de télémétrie — et en mode enforce, le projet de la clé devient le tenant qui fait autorité : un émetteur qui ment sur son tenant atterrit là où sa clé l'indique. Le mode log par défaut laisse le pipeline strictement identique : la promesse OTLP « prise en charge directe » survit à la mise à jour.
• Une démo que vous pouvez donner à n'importe qui. Un clic sur la page de connexion ouvre une session de lecteur en lecture seule, restreinte à un seul projet ; le mot de passe partagé reste côté serveur et n'atteint jamais le navigateur. À combiner avec la surcouche astronomy-shop pour des données réelles dans tous les modules.
• Le module green sur les VM cloud. Les instances de cloud public n'exposent aucun compteur de puissance : un modèle optionnel comble désormais ce trou — chaque chiffre modélisé étant étiqueté estimé de bout en bout, jamais mélangé à l'énergie mesurée, avec un panneau de couverture qui rend visible la part de flotte sans RAPL (détails).
• Contrôle de la collecte à chaud — les fondations. Le hub sait désormais stocker et servir une surcouche de collecte bornée et validée par schéma, derrière un réglage désactivé par défaut et des droits minimaux. L'applicateur et l'interface éditable arrivent ensuite ; aujourd'hui, la collecte se configure toujours par les valeurs Helm.
• Rupture : avuruops devient avuruobs. Le chart Helm, les variables d'environnement AVURUOBS_*, les chemins de montage et les noms de ressources générés correspondent enfin au nom du projet. Une mise à jour depuis une 0.2.x n'est pas un simple helm upgrade — suivez le guide de mise à jour, qui propose une voie sans renommage (--set nameOverride=avuruops) et une voie d'installation propre.

Également corrigé : une installation neuve avec la démo activée pouvait se retrouver sans compte administrateur (le lecteur de démo satisfaisait la condition d'amorçage : admin n'était jamais créé et chaque connexion échouait comme si le mot de passe était faux) — les installations concernées se réparent d'elles-mêmes au redémarrage suivant. Plus : un échec de rendu Helm à la première installation, le visiteur de démo qui atterrissait sur le mauvais projet, et la connexion derrière un reverse proxy sur un port non standard.

Les notes complètes sont sur la page Versions et dans la version GitHub. Le tronc est désormais en 0.4.0-SNAPSHOT — la suite sur la feuille de route : les projets membres multi-clusters, le plan de contrôle de la collecte terminé de bout en bout, et une compatibilité d'ingestion élargie.

• Les deux moitiés de la référence étaient fausses. Les dépôts nommaient des coordonnées Docker Hub que personne ne publie, alors que les versions sont poussées vers ghcr.io/avuruvision/avuru-obs-<composant> ; et le tag reprenait par défaut l'appVersion du chart — du SemVer nu, sans v initial — alors que seuls vX.Y.Z et vX.Y étaient poussés. Corriger l'un sans l'autre n'aurait fait que remplacer une référence introuvable par une autre : les deux sont donc corrigées. Les quatre dépôts internes pointent vers le registre, et le workflow publie désormais aussi le tag X.Y.Z nu.
• L'estimation TDP du module green n'avait aucune image. Son dépôt était vide : activer l'estimateur produisait une référence sans nom ni tag. Elle reprend maintenant le même comportement par défaut que les trois autres images internes.

Si vous êtes en v0.3.0, faites un helm upgrade vers 0.3.1 : vous pouvez alors retirer les --set hub.repository=… / --set …tag=… ajoutés pour contourner le problème. Les installations qui épinglent leurs images volontairement — registre privé via image.registry, miroirs hors ligne — ne sont concernées dans aucun des deux cas.

Voir la page Versions et la version GitHub.

• Honnête par construction. Chaque chiffre produit par l'estimateur est marqué estimé sur toute la chaîne — SQL, API, interface et bloc méthodologie de l'export CSRD — et n'est jamais mélangé à l'énergie mesurée par RAPL. Pour un même service, énergie estimée et mesurée apparaissent en lignes distinctes : un total ne peut donc pas confondre les deux silencieusement. Les estimations valent pour la tendance et la détection de régression (erreur typique de ±30 à 50 %), pas pour un audit.
• La part sans RAPL devient visible. /green gagne un panneau de couverture qui répartit la flotte entre nœuds connus, mesurés, estimés et absents. Ce qui manquait en silence devient visible, donc actionnable.
• Les budgets en tiennent compte. Les budgets carbone intègrent l'énergie estimée — le budget d'une flotte 100 % VM peut donc réellement être dépassé — et un dépassement précise la part modélisée face à la part mesurée.
• Des coefficients sourcés. La table de puissance CPU embarquée est citée (Cloud Carbon Footprint, recoupée avec le notebook d'origine dérivé de SPECpower), et les opérateurs peuvent surcharger P_idle/P_max par nœud ou pour toute la flotte.

Activez-la avec sensor.green.estimation.enabled (qui requiert sensor.green.enabled : l'estimateur est un repli sur le même signal d'énergie, pas une seconde source). Voir la documentation du module green.

• C'est la clé qui détermine le projet. Créez vos clés dans Paramètres → Général → Clés d'API d'ingestion (ou via POST /api/v1/projects/{project}/keys). En mode enforce, le projet de la clé validée devient le tenant qui fait autorité et écrase toute valeur fournie par l'émetteur. Un émetteur mal configuré — ou malveillant — ne peut plus écrire dans un projet qui ne lui a jamais été accordé.
• Le secret n'est affiché qu'une seule fois. Seule son empreinte SHA-256 est conservée : la clé brute est donc irrécupérable, aussi bien depuis la base que depuis l'API. La liste n'affiche qu'un préfixe court et des métadonnées pour l'identification ; la révocation est immédiate.
• Votre chemin d'ingestion reste rapide. Les clés sont validées dans la gateway, par une extension de collecteur dédiée. Le hub ne répond qu'à une question de plan de contrôle : il n'est jamais sur le chemin des octets de télémétrie. Les verdicts sont mis en cache et un verdict en cache continue de servir pendant un redémarrage du hub — une coupure du plan de contrôle ne peut pas faire perdre de trafic.
• Un déploiement en trois étapes, pas un interrupteur. auth.ingest.mode passe de off à log puis enforce. log est la valeur par défaut : les clés sont validées et les refus potentiels comptabilisés, mais rien n'est rejeté et le pipeline reste identique à l'octet près. Vous obtenez ainsi la liste exacte des émetteurs qui casseraient avant qu'ils ne cassent. Basculez en enforce une fois ce compteur à zéro.
• Les émetteurs existants continuent de fonctionner. La mise à jour ne change rien par elle-même : la promesse « remplacement direct » est tenue. Le chart provisionne et enregistre également une clé pour le capteur de nœud, si bien qu'activer enforce ne coupe jamais votre propre agent.

• Créer, renommer, supprimer — depuis l'application. Une carte de projet réservée aux administrateurs, dans Paramètres → Général, ajoute de nouveaux projets, modifie le nom d'affichage d'un projet et supprime ceux gérés par l'UI. Le sélecteur de la barre latérale et l'onglet Général reflètent les changements immédiatement. Les non-administrateurs conservent une visibilité en lecture seule sur les projets qui leur sont accordés.
• Les projets définis par le déploiement restent protégés. Le projet intégré default et tout projet déclaré dans le chart (valeur projects / AVURUOBS_PROJECTS) sont clairement identifiés et ne peuvent être ni modifiés ni supprimés depuis l'UI — l'application refuse avec un 409, de sorte que votre configuration de référence l'emporte toujours.
• Un identifiant stable, un nom modifiable. L'identifiant d'un projet est un slug de tenant immuable — la clé de partition de chaque trace, log et métrique ; seul son libellé d'affichage est modifiable. Renommer ou supprimer ne réécrit jamais la télémétrie : une suppression retire l'entrée et ses données expirent selon la rétention existante, et un tenant encore actif réapparaît simplement en tant que découvert automatiquement.
• Contrôlé côté serveur, réservé aux administrateurs. Les nouveaux points d'accès POST / PUT / DELETE /api/v1/projects exigent un administrateur global (403 sinon), et GET /api/v1/projects renvoie désormais le source, le label et l'indicateur editable de chaque projet. Voir la référence API.
• Les fondations de la suite. Il s'agit de la première tranche du travail sur les projets ; les clés d'ingestion par projet et les vues d'agrégation multi-clusters s'appuient sur le même modèle.

• Un clic, aucune configuration. Un bouton « Essayer la démo » sur la page de connexion vous connecte directement en lecteur en lecture seule, limité à un projet demo — aucun compte à créer, rien à installer. Le reste de l'application se comporte exactement comme pour un vrai utilisateur ; les actions d'écriture (triage, paramètres, administration des utilisateurs) ne sont simplement pas proposées.
• Des données réelles, dans chaque module. La démo est alimentée par la boutique OpenTelemetry Astronomy Shop en direct — une véritable application multi-services — de sorte que la carte des services, les traces, les logs, les métriques RED, le suivi des erreurs, la santé des services et les vues énergie affichent des données réelles et vivantes plutôt que des captures d'écran figées.
• Sûre par conception. La démo est une unique identité à faibles privilèges : le mot de passe partagé reste côté serveur (un point de connexion à débit limité) et n'atteint jamais le navigateur, et l'ensemble de la fonctionnalité est opt-in — une installation normale n'expédie ni utilisateur ni projet de démo. Activez-la avec auth.demo.enabled.
• Aussi dans cette version. L'onglet Utilisateurs des Paramètres s'ouvre désormais sur place au lieu de changer de page, si bien que la barre d'onglets ne disparaît plus ; le logo de connexion affiche Avuru Obs. Voir la référence API pour le nouveau point de connexion de la démo.

• Sécurisé par défaut. Les nouvelles installations exigent une connexion (auth.enabled=true) ; Helm amorce un utilisateur admin dont le mot de passe vit dans le Secret de la release. Chaque route de l'API est contrôlée côté serveur, et l'en-tête de projet est validé contre les droits de l'appelant — les projets deviennent une vraie frontière de sécurité : un utilisateur limité à staging reçoit 403 partout ailleurs et un sélecteur de projet qui ne liste que staging. auth.enabled=false rétablit l'ancien comportement ouvert. Voir Sécurité.
• Des rôles × des projets, pas un labyrinthe d'ACL. Trois rôles fixes — Admin, Éditeur, Lecteur — accordés par projet (ou * pour tous). Une page de connexion et un écran d'administration Paramètres → Utilisateurs les accompagnent ; la surface d'API est décrite dans la référence API.
• Connectez-vous avec l'IdP de votre entreprise. Le hub exécute lui-même le flux OIDC authorization-code + PKCE (/api/v1/auth/oidc/start → IdP → /api/v1/auth/oidc/callback) — pas de pod supplémentaire, pas de proxy en frontal. La découverte du fournisseur échoue bruyamment au démarrage : un issuer erroné arrête le déploiement au lieu de livrer une page de connexion cassée, et une connexion SSO aboutit à la même session côté serveur qu'une connexion locale.
• Accès par groupes, zéro administration par utilisateur. auth.oidc.mapping associe déclarativement les groupes de l'IdP à un rôle sur des projets (avec un repli defaultRole). Les groupes sont rafraîchis à chaque connexion SSO et le mapping est appliqué à chaque requête depuis le fichier de configuration rechargé à chaud (~15 s, sans redémarrage) — un changement de politique d'accès prend effet sans toucher aux comptes individuels.
• forceSSO pour une politique centralisée. Masque le formulaire de mot de passe local afin que l'IdP soit la seule porte d'entrée pour les personnes — la connexion admin locale par l'API reste disponible en secours. Tout se configure depuis les values Helm (auth.oidc.*) ; le secret client provient de votre propre Secret ou d'un Secret géré par le chart, jamais du fichier de configuration.
• Des sessions réellement révocables. Les sessions sont côté serveur (la révocation est immédiate), les connexions sont limitées en débit, et l'état vit dans la base de données existante — aucun composant nouveau.
• Consultation anonyme opt-in. Accordez aux visiteurs un rôle sur une liste explicite de projets uniquement : une démo publique peut partager un projet pendant que tous les autres restent invisibles.

• Une page de licence réellement lisible. Une nouvelle page Licence et pérennité (EN + FR) répond aux vraies questions que les gens se posent : l'auto-hébergement est sans obligation, observer vos services n'en fait jamais des œuvres dérivées, et l'AGPL ne vous demande quelque chose que si vous modifiez avuru obs lui-même et le proposez à des tiers via un réseau.
• Rien n'est réservé à une offre payante. Authentification, rôles, contrôle d'accès par projet et SSO OIDC — des capacités souvent verrouillées derrière un palier payant ailleurs — sont dans l'édition open source. AGPL-3.0, pour toujours.
• Chaque contribution reste ouverte. Le §2.2 de l' accord de licence de contribution garantit juridiquement que chaque contribution reste disponible sous AGPL-3.0 — l'édition open source ne peut jamais être fermée ni amputée rétroactivement.
• Le capteur reste en Apache-2.0. L'agent de nœud eBPF est l' OpenTelemetry eBPF Instrumentation (OBI) en amont, configuré — non forké — et conserve donc sa licence permissive.
• Attribution des tiers, générée et non tenue à la main. Une cible make notices produit THIRD-PARTY-NOTICES.md à partir des arbres de dépendances Go et TypeScript réels, intégrée à la checklist de release pour que l'attribution ne s'écarte jamais de ce qui est livré.
• Pourquoi l'AGPL, dit franchement. Une plateforme d'observabilité détient la télémétrie la plus sensible qu'une organisation produise. avuru obs est conçu comme une alternative souveraine à la facturation SaaS par hôte — et l'AGPL est ce qui empêche l'édition open source d'être enfermée dans le service fermé de quelqu'un d'autre.

• Sécurisé par défaut. Le hub exige désormais une connexion : des utilisateurs locaux avec les rôles Admin, Éditeur et Lecteur, accordés par projet et appliqués côté serveur sur chaque route de l'API — les projets deviennent une vraie frontière de sécurité, pas un simple filtre. Ajoutez le SSO d'entreprise avec n'importe quel fournisseur OpenID Connect (correspondance groupe→rôle, forceSSO pour les flottes 100 % IdP) — sans proxy annexe, sans pod supplémentaire (guide sécurité).
• Choisissez vos signaux. Un interrupteur par famille de signaux (modules.<name>.enabled) contrôle d'un bloc son schéma, son API, son pipeline, sa collecte et son interface — une installation « traces uniquement » ne porte aucun poids de logs ni de profils, et la barre latérale suit ce que l'installation annonce.
• Suivi des erreurs. Les exceptions déjà présentes dans vos spans et vos logs deviennent des problèmes dédupliqués et triables — pile d'appels, chronologie des occurrences, lien vers la trace d'origine, cycle de vie résolu/ignoré avec détection des régressions. Les applications navigateur remontent aussi, en changeant un seul DSN — le signal que l'eBPF ne peut pas atteindre.
• Santé des services & alertes. Regroupez les services avec des niveaux de criticité (T0/T1/T2) et une propagation par dépendance — un service ne peut pas s'afficher vert quand une dépendance critique est rouge — puis recevez un webhook (protégé contre les SSRF, avec cycle déclenché/résolu) quand un groupe bascule en mauvais état.
• Santé réseau sur la carte. RTT par liaison et compteurs de connexions échouées/réinitialisées issus des statistiques TCP eBPF — la santé au niveau connexion, sans traces ni SDK.
• Green : énergie & carbone. Wh et gCO2e par service mesurés au niveau du nœud (opt-in, matériel RAPL), budgets carbone mensuels avec alertes, et un export prêt pour la CSRD qui explicite sa méthodologie. Rien ne sort du cluster.
• Un capteur qu'on peut laisser activé, preuve à l'appui. La CI maintient un canari sensible aux sondes en bonne santé pendant un test d'endurance avec le capteur attaché ; les flottes prudentes disposent d'un mode de découverte opt-in et d'un guide de déploiement progressif.
• AGPL-3.0. Le projet est désormais sous licence AGPL-3.0.

Retrouvez les notes complètes sur la page Versions et la version GitHub. Le tronc est désormais en 0.3.0-SNAPSHOT — prochaines étapes sur la feuille de route : les clés d'ingestion par projet, le plan de contrôle de la collecte à chaud, et une compatibilité d'ingestion élargie.

• Des chiffres qu'un auditeur peut reproduire. Un export CSV/JSON prêt pour la CSRD porte un bloc méthodologie — la formule, le facteur d'intensité du réseau et sa provenance, le ratio de couverture de mesure et un seau non attribué explicite — pour qu'un gCO2e reporté soit traçable jusqu'à sa production.
• Des budgets carbone par équipe. Des budgets mensuels de gCO2e par groupe de services, avec alerte à 80 %, dépassement à 100 % et une projection de fin de mois — livrés via les canaux d'alerting que vous avez déjà configurés. Alerting désactivé, les budgets affichent quand même leur statut sur le tableau de bord.
• Une efficacité démontrable. Intensité carbone par requête (Wh ÷ requêtes, gCO2e dérivé) et tendance par service, pour qu'une optimisation ressorte même quand le trafic augmente — plus une superposition gCO2e sur la carte des services que vous surveillez déjà.
• Hors ligne par conception. Les facteurs d'intensité du réseau sont des moyennes annuelles par pays intégrées, avec surcharges opérateur en configuration ; gCO2e = Wh × intensité × PUE s'exécute dans le hub au moment de la requête. Aucune sortie réseau, compatible air-gap.
• Aucun nouveau stockage, aucun changement de code. Tous les calculs s'exécutent sur les tables de métriques déjà existantes — pas de migration. Kepler rejoint le sensor comme conteneur opt-in et sans sonde (sensor.green.enabled), il ne peut donc jamais déstabiliser le pod du sensor ; et sur les nœuds sans RAPL, le module rapporte honnêtement (un ratio de couverture et un état vide pédagogique) au lieu d'estimer.
• Désactivé par défaut. Le signal dépend du matériel RAPL/powercap : modules.green.enabled est donc livré désactivé — une installation existante se met à jour sans changement. Il nécessite le module infra-metrics pour la jointure pod→charge.

:::caution À confirmer sur du matériel réel avant la production Les noms de métriques, clés de configuration et port de Kepler sont validés en CI avec le compteur de développement de l'image épinglée, mais doivent être confirmés sur du matériel RAPL réel avant une utilisation en production. Les noms de métriques du hub sont configurables précisément pour cette raison. Voir la page Green. :::