Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Les dépendances élargissent la fenêtre d'exposition, car les versions de Celery arrivées en fin de vie (EOL) vous maintiennent liés à d'anciennes branches « kombu », « billiard » et « vine » qui ne bénéficient plus de correctifs de sécurité rétroactifs.
- Les mises à niveau précipitées sont coûteuses et risquées, car le passage de Celery 4.x à 5.x peut entraîner des modifications au niveau de l'environnement d'exécution, de l'interface de ligne de commande, du backend et des dépendances, susceptibles de perturber les flux de travail en production.
- La fin de vie (EOL) de Celery ne signifie pas la fin de la sécurité, car TuxCare ELS continue d'assurer la prise en charge des versions EOL de Celery pendant que vous procédez à la mise à niveau selon votre propre calendrier.
Si vous exécutez des tâches en arrière-plan en Python, il y a de fortes chances que Celery soit impliqué. Envoi d’e-mails, génération de rapports, traitement des paiements, pipelines d’inférence d’apprentissage automatique, exportations de données planifiées : Celery gère les tâches asynchrones qui assurent le bon fonctionnement des applications de production. Il remplit cette fonction depuis près de 17 ans, est téléchargé près de 50 millions de fois par mois sur PyPI, et constitue le genre d’infrastructure qui s’efface discrètement à l’arrière-plan de chaque pile logicielle qu’il touche.
C'est précisément pour cette raison que les situations de fin de vie (EOL) de Celery ont tendance à prendre les équipes au dépourvu.
Celery ne dispose pas d’une politique officielle de support à long terme. Le projet indique explicitement qu’il prend en charge la série 5.x actuelle jusqu’à la sortie de Celery 6.x, et Celery 4.x a été déclaré non pris en charge dès que la version 5.x est devenue stable. Il n’y a ni fenêtre de maintenance, ni calendrier de rétroportage, ni engagement concernant les correctifs de sécurité pour les anciennes versions. Lorsqu’une version est remplacée, c’est terminé.
Ainsi, si vous utilisez une version de Celery en fin de vie (EOL), qu’il s’agisse d’une version 4.x ou d’une version 5.x « fixée » plus ancienne, avec quelques versions mineures de retard, vous êtes déjà, dans les faits, en situation de fin de vie. Voyons ce que cela implique concrètement pour vos files d’attente de tâches en production.
Comment fonctionnent réellement les publications Celery ?
Avant d'aborder ce que signifie concrètement la notion d'EOL, il est utile de comprendre comment Celery gère le cycle de vie de ses propres versions, car le projet fait preuve d'une transparence inhabituelle à ce sujet.
Celery a été créé par Ask Solem et lancé pour la première fois en 2009. La série 4.x s'est étendue de 2016 à environ 2021, date à laquelle Celery 5.2 a été publié. À ce moment-là, l'équipe du projet a explicitement annoncé qu'elle ne disposait plus des ressources nécessaires pour assurer la maintenance de Celery 4.x. Depuis lors, cette version n'est plus prise en charge et aucun correctif de sécurité n'est publié pour aucune version 4.x.
La série 5.x actuelle suit le même schéma pour l'avenir : Celery 5.x sera pris en charge jusqu'à la sortie de Celery 6.x. Il n'y a pas de désignation LTS, ni d'annonce officielle indiquant à quel moment une version mineure de la série 5.x cessera de bénéficier de correctifs. Le projet continue simplement d'évoluer, et les versions « épinglées » qui prennent du retard accumulent des vulnérabilités non corrigées.
La politique de prise en charge des versions de Python illustre bien cela. Celery 5.0 nécessitait Python 3.6 ou une version ultérieure. Celery 5.2 a cessé de prendre en charge Python 3.6. Celery 5.4 a cessé de prendre en charge Python 3.7. Celery 5.6 a cessé de prendre en charge Python 3.8, exigeant désormais au minimum Python 3.9. La version stable actuelle est la 5.6.x. Si vous utilisez une version antérieure, vous utilisez un logiciel pour lequel le projet ne publie plus de correctifs.
Il n'y a pas de sécurité partielle ici. Une équipe utilisant Celery 4.4.7 avec un fichier de dépendances verrouillé ne se trouve pas dans une « fenêtre de maintenance » ; elle est livrée à elle-même.
Ce que signifie réellement la fin de vie de Celery pour votre environnement de production
Vos processus fonctionnent, vos tâches sont en cours d'exécution et vos files d'attente semblent en bon état. Tout va bien. Alors pourquoi la fin de vie est-elle importante pour un élément aussi invisible sur le plan opérationnel ?
Les chercheurs en sécurité n'attendent pas que vous effectuiez une mise à jour pour détecter des failles. Les pirates ciblent spécifiquement les logiciels d'infrastructure largement déployés qui fonctionnent sur des versions en fin de vie, précisément parce qu'ils savent qu'aucun correctif ne sera publié. Et Celery est l'un des logiciels d'infrastructure Python les plus largement déployés qui soient.
Les versions de Celery en fin de vie présentent des risques de sécurité avérés, et la nature de ces vulnérabilités est particulièrement préoccupante pour l'infrastructure des files d'attente de tâches.
CVE-2021-23727 (CVSS 7.5, High): A stored command injection vulnerability affecting all Celery versions before 5.2.2. By default, Celery trusts the messages and metadata stored in result backends without validation. When reading task metadata from the backend, the data is deserialized using a function that performs recursive attribute lookups based on a Python dotted path, loading whatever module and class the stored metadata specifies. An attacker who can access or manipulate metadata in the Celery result store can inject a payload like {‘exc_module’: ‘os’, ‘exc_type’: ‘system’, ‘exc_message’: ‘your_command’} and have it executed as an OS command when the worker processes that task result. The result: arbitrary command execution on the worker host, with potential for full system takeover or lateral movement into the broader infrastructure. IBM flagged this CVE in security advisories for multiple enterprise products, including IBM Spectrum Protect Plus and IBM QRadar. It affects every Celery deployment on a version before 5.2.2 that uses a result backend, which is the overwhelming majority of production Celery setups.
Si vous utilisez Celery 4.x, vous êtes exposé à cette vulnérabilité et aucun correctif officiel n'est disponible pour votre version. Si vous utilisez une version 5.x antérieure à la 5.2.2, la situation est identique.
Au-delà des vulnérabilités directes de Celery lui-même, les cadres de conformité ne font preuve d’aucune indulgence envers les logiciels d’infrastructure qui ne bénéficient plus d’un support technique. La norme PCI DSS exige que les vulnérabilités de gravité élevée soient corrigées dans un délai de 30 jours. Les auditeurs SOC 2 posent des questions spécifiques sur les logiciels qui ne bénéficient plus d’un support technique dans les environnements de production. L’utilisation de versions de Celery en fin de vie (EOL) est considérée comme une lacune dans la documentation lors de chaque audit de sécurité auquel votre organisation est soumise.
Le risque caché : votre chaîne de dépendances
Lorsque les équipes évaluent la sécurité de Celery, elles ont tendance à se concentrer sur la file d’attente des tâches elle-même, les pools de travailleurs, l’acheminement des tâches et la limitation de débit. C’est un point de départ raisonnable, mais cela ne tient pas compte de l’étendue réelle de la fenêtre d’exposition.
Les dépendances principales de Celery sont toutes gérées sous l’égide du même projet Celery : kombu (la bibliothèque de messagerie qui fait abstraction de RabbitMQ, Redis et d’autres brokers), billiard (le fork de multiprocessing qui alimente le pool de workers prefork) et vine (la bibliothèque de promesses/callbacks pour la composition de tâches asynchrones). Celery 5.x nécessite en outre click et ses composants associés pour l’interface en ligne de commande (CLI). Il ne s’agit pas d’ajouts facultatifs ; ils sont indispensables au bon fonctionnement de toute installation de Celery.
The version pinning relationship matters here. Celery 4.4.7 requires kombu <4.7,>=4.6.10 and billiard <4.0,>=3.6.3.0. Celery 5.3.x requires kombu <6.0,>=5.3.4. These are hard constraints. When you’re pinned to a Celery EOL version, you’re also pinned to old ranges of all the core dependencies, and the Celery project does not backport security patches to those older kombu, billiard, or vine branches.
Kombu gère l'ensemble de la sérialisation et de la désérialisation des messages pour la communication avec le broker Celery. Billiard assure le fonctionnement du pool de workers. Si une vulnérabilité CVE est identifiée dans la version figée de l'un ou l'autre, celle-ci reste non corrigée, tout comme la version de Celery en fin de vie.
Il en résulte une fenêtre d'exposition qui s'élargit. pip audit peut signaler les CVE dans vos paquets installés dès leur divulgation, mais il ne peut pas appliquer les correctifs aux versions de paquets en fin de vie. La surface de vulnérabilité s’étend à l’ensemble de l’arborescence des dépendances, et pas seulement à la couche de file d’attente des tâches située au sommet.
Que faire lorsque le céleri arrive en fin de vie ?
Votre version de Celery est donc en fin de vie, ou en passe de l'être. Quelles sont les solutions réalistes qui s'offrent à vous ?
Deux d'entre elles impliquent des coûts élevés, une planification complexe et des risques opérationnels. La troisième – l'extension de la prise en charge – est l'option qui résout réellement le problème de sécurité sans vous obliger à effectuer une migration pour laquelle vous n'êtes pas prêt, et c'est celle que la plupart des équipes auraient aimé découvrir plus tôt.
Option 1 : Passer à une version récente de Celery
La réponse officielle : passez à la dernière version de Celery (5.6.x), bénéficiez d'une couverture de sécurité active et profitez des améliorations en matière de stabilité que le projet a apportées au fil de plusieurs versions mineures.
Et la version actuelle de Celery est véritablement meilleure. Les fuites de mémoire liées à la gestion des exceptions ont été corrigées. Les problèmes de stabilité du broker Redis qui affectaient les versions 5.x antérieures ont été résolus. La prise en charge de Python 3.13 et 3.14 a été ajoutée. Pour les équipes qui exploitent des bases de code activement maintenues, la mise à niveau est la bonne décision à long terme.
Mais la mise à niveau d'un système de production sur une version Celery en fin de vie se déroule comme suit :
La compatibilité avec Python 2 a complètement disparu : Celery 5.x a complètement abandonné la prise en charge de Python 2. Si une partie quelconque de votre code de tâche ou de vos backends personnalisés reposait sur des modèles Python 2, il faudra y remédier avant même de pouvoir procéder à la mise à niveau. Pour les organisations disposant d’applications Django héritées fonctionnant encore avec des workflows Python 2.7 via Celery 4.x, il ne s’agit pas d’un changement mineur ; c’est une migration en cours d’exécution qui touche l’ensemble de la pile applicative.
Changements majeurs dans l'interface CLI : L'interface CLI de Celery 5.0 a été réécrite à l'aide de Click. Les options globales qui suivaient auparavant la sous-commande doivent désormais la précéder. Les commandes telles que celery worker –app path.to.app sont devenues celery –app path.to.app worker. Tous les scripts de déploiement, commandes de démarrage de conteneurs, spécifications de pods Kubernetes ou fichiers d'unité systemd qui invoquent des workers Celery doivent être vérifiés et mis à jour.
Backends et modules supprimés : Le backend de résultat AMQP a été entièrement supprimé dans Celery 5.0. Le celery.utils.encoding et celery.task ont été supprimés. Les importations qui fonctionnaient dans Celery 4.x génèrent désormais une exception une erreur « ImportError ». Toute tâche personnalisée utilisant from celery.task import Task doivent être mises à jour pour utiliser from celery import Task. Tout code utilisant Celery.shared_task via l'ancien chemin doit être mis à jour en conséquence.
Kombu version incompatibility: Celery 4.x requires kombu <4.7. Celery 5.6.x requires kombu >=5.6. There’s no incremental path here; this is a hard dependency jump that affects how your Celery application connects to RabbitMQ, Redis, and any other broker you’re using. Broker connection behavior, serialization defaults, and connection pooling all changed between kombu 4.x and 5.x.
Migration de pytz vers zoneinfo : Celery 5.3 a remplacé pytz par le module zoneinfo intégré à Python pour la gestion des fuseaux horaires, et utilise désormais tzdata comme dépendance pour la base de données des fuseaux horaires. Toutes les tâches dont la logique de planification repose sur des objets de fuseau horaire spécifiques à pytz doivent être revues.
Pour une base de code réduite comportant seulement quelques tâches ? Cette mise à niveau s'apparente à un sprint ciblé. Pour un système de production mature comprenant des dizaines de définitions de tâches, des backends personnalisés, une automatisation du déploiement et des années de pratiques accumulées autour de l'ancienne interface en ligne de commande ? Il vous faudra alors une planification minutieuse, des tests approfondis et vous devrez faire face à un risque réel de rupture des pipelines de tâches sous la charge de production.
Option 2 : Migration vers d'autres frameworks
Certaines équipes, face à la fin de vie de Celery, estiment que c'est le moment de repenser leur approche dans son ensemble.
Dramatiq, RQ (Redis Queue), Huey ou encore des solutions natives du cloud telles qu’AWS SQS avec Lambda constituent toutes de véritables alternatives, chacune présentant des avantages et des inconvénients spécifiques qui pourraient en réalité mieux correspondre à votre situation.
Mais soyons honnêtes sur ce qu’implique la migration vers un nouveau framework. Il ne s’agit pas simplement de changer de bibliothèque. Vous réécrivez chaque définition de tâche en utilisant les modèles de décorateurs et de classes du nouveau framework. Vous remplacez les primitives de Celery (chaînes, accords, groupes) par ce que le nouveau framework utilise pour la composition des tâches, si tant est qu’il le prenne en charge. Vous reconstruisez votre infrastructure de surveillance, la configuration de déploiement de vos workers, votre logique de réessai et de backoff, ainsi que l’intégration de votre backend de résultats. Et vous faites tout cela tout en maintenant le système existant opérationnel en production.
Les avantages architecturaux à long terme peuvent tout à fait justifier ces travaux lorsque les conditions s'y prêtent. Le calendrier et les coûts réels dépassent presque toujours largement les estimations initiales. Et la période pendant laquelle vos opérateurs de production utilisent une version de Celery en fin de vie (EOL) alors que la migration est en cours correspond exactement à la fenêtre de vulnérabilité que vous cherchiez à combler.
Option 3 : Assistance étendue par un tiers
Il existe une troisième solution à laquelle on ne s'intéresse pas assez : le support de sécurité prolongé proposé par des entreprises spécialisées précisément dans ce domaine.
TuxCare propose une assistance tout au long du cycle de vie pour les versions de Celery arrivées en fin de vie (EOL). Ainsi, vous n’êtes pas obligé de procéder à une migration pour laquelle vous n’êtes pas encore prêt, ni de laisser vos files d’attente de tâches exposées pendant que vous planifiez celle-ci : vous continuez à utiliser votre version actuelle de Celery tout en bénéficiant d’une couverture continue des correctifs de sécurité.
Le principe est simple : vous gagnez en temps et en maîtrise. Du temps pour planifier une mise à niveau en bonne et due forme, au moment où cela s'inscrit réellement dans votre feuille de route technique. La maîtrise de votre calendrier de migration, au lieu d'être à la merci d'une divulgation de CVE qui vous oblige à agir au pire moment possible, comme celles qui surviennent un vendredi après-midi.
Le coût réel d'une mise à niveau précipitée de Celery vers la version EOL
Voyons ce qui se passe concrètement lorsque des équipes doivent condenser une migration Celery EOL dans un délai irréaliste, parce qu’un audit de sécurité vient de signaler l’utilisation d’une version non prise en charge.
Augmentation de la charge de support : Les différences de comportement entre Celery 4.x et 5.x qui n’étaient pas apparues en environnement de préproduction commencent à se manifester en production. Des tâches qui s’exécutaient sans problème dans Celery 4.x génèrent désormais des erreurs qui étaient auparavant ignorées. Des échecs d’appel de l’interface CLI dans les scripts de déploiement qui semblaient fonctionner correctement lors des tests. Un comportement du pool de connexions Kombu légèrement différent en cas de débit élevé. Votre file d’attente d’astreinte se remplit d’incidents qui sont tous liés à la migration.
Instabilité du système : Les déploiements Celery EOL s’exécutent dans des environnements distribués comportant plusieurs nœuds de travail, des brokers partagés et des backends de résultats partagés. De subtiles incompatibilités dans la manière dont les différentes versions de Celery gèrent la sérialisation des tâches ou le stockage des résultats peuvent entraîner des défaillances extrêmement difficiles à reproduire en dehors d’une charge de production. Ce sont ces problèmes qui génèrent des alertes à 3 heures du matin et des ingénieurs véritablement mécontents.
Accumulation de dette technique : Dans la précipitation pour assurer la conformité, des shims de compatibilité sont ajoutés. Les modules de tâches sont encapsulés avec des blocs try/except ImportError . Les anciennes options de l’interface en ligne de commande (CLI) sont redirigées via des scripts de contour avec des commentaires indiquant « corriger cela correctement plus tard ». Six mois après la migration, vous utilisez techniquement la version actuelle de Celery, mais votre infrastructure regorge de solutions de contournement qui rendent la prochaine mise à niveau encore plus difficile.
Dépassements budgétaires : L’estimation initiale était de quatre semaines. Dix semaines plus tard, vous êtes toujours en train de déboguer le comportement de la connexion au broker et de traquer des échecs de tâches intermittents qui n’apparaissent que sous la charge de production. Le prestataire appelé à la rescousse continue de facturer ses services. Le développement des fonctionnalités prévues a été repoussé de deux trimestres. Le coût d’opportunité lié au fait que vos ingénieurs backend seniors passent leur temps à déboguer des cas limites de sérialisation Celery au lieu de développer un produit est bien réel.
La mise à niveau est la bonne solution à long terme. Une migration précipitée suite à la fin de vie de Celery, sous la pression de la conformité, constitue un scénario d'échec bien précis et tout à fait prévisible. Ce ne sont pas deux choses identiques.
La solution simple : TuxCare ELS pour les versions de Celery arrivées en fin de vie
C'est là que le support à vie proposé par TuxCare pour Celery change véritablement la donne.
TuxCare mène cette mission depuis plus d’une décennie, en fournissant des correctifs de sécurité pour les systèmes d’exploitation, les environnements d’exécution, les bibliothèques et les frameworks d’application en fin de vie. L’entreprise a diffusé plus de 220 000 correctifs de sécurité à travers l’écosystème open source. Lorsqu’elle affirme savoir comment assurer la sécurité des logiciels en fin de vie à l’échelle de l’entreprise, elle l’a véritablement prouvé à grande échelle, à maintes reprises, pour le compte de certaines des plus grandes organisations mondiales.
En quoi l'approche de TuxCare est-elle différente ?
Couverture complète de la chaîne de dépendances : C’est particulièrement important pour Celery, étant donné à quel point les fonctionnalités du framework dépendent étroitement de kombu, billiard et vine. TuxCare ne se contente pas d’appliquer des correctifs à Celery lui-même ; l’entreprise couvre également vos dépendances directes ainsi que les dépendances transitives sous-jacentes, le tout sans frais supplémentaires. Qu’il s’agisse des failles de sécurité de kombu, des vulnérabilités de billiard ou des risques liés à vine, TuxCare assure une protection complète. Vous ne vous contentez pas de protéger la file d’attente des tâches ; vous sécurisez l’ensemble de la pile de dépendances de Celery.
Processus de correction optimisé et automatisé : Le processus de TuxCare allie une automatisation poussée à une validation par des experts. L’équipe surveille le NVD, les avis de sécurité des éditeurs, les flux de sécurité GitHub et toutes les sources où sont divulguées les vulnérabilités de Celery en fin de vie. Lorsqu’un CVE est publié, elle utilise des outils algorithmiques et une automatisation assistée par l’IA pour rétroporter les correctifs de sécurité vers les versions en fin de vie, puis des experts en sécurité valident chaque correctif avant sa diffusion. Chaque mise à jour est soumise à des tests d’intégrité, de fonctionnalité et de régression avant d’atteindre vos dépôts. Vous souhaitez découvrir exactement comment cela fonctionne ? Consultez livre blanc technique de TuxCare consacré à son processus de correction des logiciels open source.
Intégration transparente : Les correctifs de TuxCare s’intègrent directement à votre workflow pip existant. Que vous utilisiez pip, Poetry ou n’importe quel gestionnaire de paquets Python standard, les paquets ELS fonctionnent tout simplement. Vous n’avez pas besoin de remanier vos pipelines de déploiement ni de former à nouveau votre équipe. Vous continuez à utiliser exactement ce que vous avez déjà mis en place.
Réponse rapide garantie par un SLA : Lorsque de nouvelles vulnérabilités de fin de vie (EOL) de Celery sont révélées, TuxCare fournit des correctifs couverts par de véritables accords de niveau de service. Vous n’avez plus à croiser les doigts en espérant que quelqu’un finisse par rétroporter un correctif. Vous bénéficiez de mises à jour de sécurité prêtes à l’emploi dans des délais garantis, avec une assistance réelle en cas de problème.
Rentabilité : Voici ce qui surprend la plupart des équipes concernant le support prolongé : il est généralement nettement moins coûteux que les autres solutions. Lorsque l’on additionne le temps de travail des ingénieurs aux tarifs horaires réels, les cycles de test, les honoraires des prestataires, les temps d’arrêt potentiels, les retards dans le déploiement des fonctionnalités et le coût d’opportunité, l’ELS ne représente généralement qu’une fraction de ce total. De plus, vous évitez d’épuiser votre équipe dans le cadre d’une migration sous haute pression liée aux exigences de conformité.
Conformité et transparence : Chaque version de TuxCare offre une visibilité complète sur les correctifs apportés : quels CVE ont été corrigés, quels composants ont été modifiés et comment vérifier l’ensemble de votre nomenclature logicielle (SBOM). C’est exactement ce dont vous avez besoin pour les audits PCI DSS, les examens SOC 2 et tout autre cadre de conformité qui pose des questions précises sur les logiciels en fin de vie utilisés en production.
Comment démarrer
Si vous utilisez des versions de Celery arrivées en fin de vie (EOL) et que vous souhaitez connaître la couverture réellement disponible, TuxCare met à jour en temps réel un outil de suivi des CVE qui vous permet de consulter les vulnérabilités et les correctifs disponibles pour Celery.
Vous souhaitez avoir une vue d'ensemble des versions prises en charge, des tarifs et de la mise en œuvre ? Rendez-vous sur la page « Assistance à cycle de vie illimité pour Celery » de TuxCare pour plus de détails.
Ne laissez pas la fin de vie de Celery mettre vos files d'attente de tâches en danger
Celery a connu un parcours remarquable. Depuis plus de 15 ans, il constitue la colonne vertébrale du traitement des tâches en arrière-plan sous Python. Il gère les opérations asynchrones de certains des systèmes de production les plus complexes au monde, et ce, avec une telle discrétion que la plupart des ingénieurs en oublient sa présence jusqu’à ce qu’un problème survienne.
Mais si vous utilisez des versions de Celery en fin de vie (EOL) en production, qu’il s’agisse d’une installation figée en version 4.4.x ou d’une version 5.x plus ancienne, le fait qu’il « continue à traiter des tâches » ne signifie pas pour autant qu’il « reste sécurisé ».
La fin de vie (EOL) de Celery ne doit pas nécessairement être synonyme de précipitation. Vous disposez de véritables options. Vous pouvez planifier une mise à niveau mûrement réfléchie vers une version actuelle de Celery lorsque cela correspond réellement à la feuille de route de votre équipe. Vous pouvez évaluer si un autre framework serait plus adapté à votre architecture dans votre situation. Ou vous pouvez recourir au support étendu pour garantir la sécurité et la conformité tout en prenant ces décisions selon votre propre calendrier, et non selon celui d’un scanner de sécurité.
Les équipes qui gèrent efficacement les situations de fin de vie (EOL) de Celery identifient les risques dès le début, évaluent les options réellement disponibles et font des choix mûrement réfléchis plutôt que réactifs, quels que soient leur budget ou le degré de modernité de leur base de code.
Si la fin de vie de Celery vous préoccupe actuellement, cela vaut la peine de vous renseigner sur ce que propose TuxCare. Vous constaterez peut-être que sécuriser ce que vous avez déjà développé, tout en planifiant la mise à niveau que vous souhaitez réellement, constitue une meilleure étape suivante que de précipiter une migration pour laquelle vous n’êtes pas encore prêt.
Visitez le support à cycle de vie illimité de TuxCare pour les logiciels open source pour découvrir comment une assistance prolongée peut protéger l'ensemble de votre pile open source aussi longtemps que vous en avez besoin.
