Aller au contenu principal

Sécurité : les points d'API green n'exigeaient aucune session

GET /api/v1/green/summary, /green/budgets et /green/report étaient enregistrés sans l'intergiciel de session que toutes les autres routes de signal utilisent. Sur une installation dont l'authentification est pourtant activée, les trois répondaient 200 à un appelant sans aucune session.

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.