Comparaison entre KernelCare
et Red Hat kpatch

La plupart des éditeurs de Linux d'entreprise proposent désormais un outil de correction à chaud ; celui de Red Hat, baptisé « kpatch », a été intégré à RHEL dès 2014. Son projet open source en amont est toutefois désormais obsolète. kpatch applique des correctifs au noyau sur un serveur en cours d'exécution, ce qui évite d'avoir à attendre une fenêtre de maintenance pour installer les mises à jour de sécurité.

Le problème, c'est que sa couverture est très limitée. kpatch ne corrige qu'environ 10 % des vulnérabilités CVE affectant un système, en ignorant complètement l'espace utilisateur, et sa couverture expire au bout d'environ un an par noyau, ce qui oblige à effectuer les redémarrages que la correction en direct était justement censée éviter. De plus, cette protection très restreinte reste soumise à des abonnements RHEL coûteux.

La solution KernelCare de TuxCare a été conçue pour combler ces lacunes. Elle corrige toutes les vulnérabilités CVE du noyau, quel que soit leur niveau de gravité, s'étend à OpenSSL et à glibc via LibCare, et assure une couverture continue sans redémarrage forcé, le tout pour seulement 50 $ par système et par an. Le tableau comparatif ci-dessous détaille les points de divergence entre les deux solutions.

	Red Hat kpatch	KernelCare
Distributions prises en charge	Uniquement Red Hat Enterprise Linux	Red Hat Enterprise Linux 6, 7, 8, 9, ainsi qu'Ubuntu, Oracle, AlmaLinux et bien d'autres encore
Vulnérabilités corrigées	❌ Seulement environ 10 % des CVE (CVE du noyau classés « importants » et « critiques »)	✅ Couverture pouvant aller jusqu'à 100 %
Couverture du noyau Linux et des composants critiques de l'espace utilisateur (OpenSSL, glibc)	❌ Noyau uniquement	✅ Oui
Prise en charge de l'architecture ARM64	❌ x86-64 uniquement	✅ Oui
Mise à jour à chaud pour tout noyau en cours d'exécution	❌ Sélectionner uniquement les noyaux éligibles	✅ Oui
Durée de vie pratiquement illimitée des correctifs apportés au noyau	❌ Environ un an par noyau	✅ Oui
s automatisées intégrées et application des correctifs	❌ Pas d'agent dédié ; les correctifs sont fournis sous forme de paquets RPM et appliqués via yum/dnf ou Satellite	✅ L'agent vérifie et applique automatiquement les nouveaux correctifs
Corrections en temps réel pour , un système d'exploitation en fin de vie	❌ Non inclus dans l'option payante « Extended Life-cycle Support »	✅ Red Hat Enterprise Linux 6, 7, ainsi qu'Ubuntu, Oracle, AlmaLinux et bien d'autres encore
Fonctionnalité de retour en arrière sans redémarrage	❌ Après un redémarrage	✅ Sans redémarrage
Livraison de patchs personnalisés	❌ À réaliser soi-même avec kpatch-build ; non fourni ni pris en charge en tant que service	✅ Entièrement géré
Gestion centralisée et isolée physiquement	❌ Nécessite Red Hat Satellite (licence distincte)	✅ Inclus (ePortal)
API disponible	❌ L'API centralisée nécessite Red Hat Satellite (licence distincte)	✅ Inclus (ePortal)
Distribution d'un seul patchset pour tous les patchs	✅ Oui	✅ Oui
Développé activement en amont	❌ Obsolète, en mode maintenance	✅ Oui
Assistance 24/7	❌ Niveaux de gravité 1 et 2 uniquement, abonnés Premium	✅ En ligne, 24 h/24, 7 j/7, 365 jours par an
Compléments	-	LibCare, écussons personnalisés
Type de correction	Permanente	Permanente
Coût	Nécessite un abonnement RHEL actif : 878,90 $ (Standard) ou 1 428,90 $ (Premium) par système et par an ; module complémentaire EUS : +273,90 $	À partir de 50 $ par système et par an ; tarifs dégressifs disponibles

Le graphique montre les points de divergence entre les deux. La suite de cette comparaison explique ce que chacune de ces différences implique pour les systèmes que vous utilisez concrètement.

L'application de correctifs en direct doit couvrir les systèmes que vous utilisez réellement, quelle que soit la combinaison de distributions qui en résulte. kpatch est développé et maintenu par les développeurs de Red Hat ; il s'agit donc, dans la pratique, d'un outil RHEL. Même au sein de RHEL, RHEL 6 et certaines versions de RHEL 7 ne sont pas prises en charge. Quelques distributions non RHEL, telles que certaines versions d’Ubuntu, de Debian et de Gentoo, sont techniquement prises en charge, mais uniquement si vous créez vous-même les correctifs en direct, ce qui nécessite une expertise approfondie du noyau et comporte un risque réel en cas d’erreur.

KernelCare adopte une approche diamétralement opposée. Il applique des correctifs à chaud à RHEL, Ubuntu, Debian, Oracle Linux, AlmaLinux, Rocky Linux, Amazon Linux et bien d'autres distributions dès son installation. Pour une entreprise utilisant une seule distribution, cela peut ne pas sembler déterminant aujourd'hui, mais cela signifie un seul outil et un seul processus de travail si votre parc informatique venait à s'étendre au-delà de RHEL.

L'intérêt même des correctifs en temps réel est de corriger rapidement les vulnérabilités ; la première question qui se pose donc est de savoir lesquelles un outil corrige réellement. Nos propres recherches ont montré que kpatch n'applique des correctifs en temps réel qu'à environ 10 % des CVE affectant un système, et cette lacune s'explique en partie par la conception même de l'outil.

kpatch n'applique des correctifs en temps réel qu'aux CVE du noyau que Red Hat classe lui-même comme « Important » ou « Critique », et ce critère est plus restrictif qu'il n'y paraît. Red Hat attribue ses propres niveaux de gravité, qui peuvent différer de la note attribuée à un CVE dans la National Vulnerability Database ; ainsi, une faille classée « Critique » ailleurs peut être reclassée à un niveau inférieur et ignorée. Ces évaluations supposent également une configuration type ; ainsi, une faille à laquelle Red Hat attribue une note inférieure peut tout de même constituer une exposition grave dans votre configuration spécifique, mais elle ne bénéficie d’aucun correctif en temps réel et doit attendre la prochaine version du noyau et un redémarrage. Et même parmi les failles que Red Hat classe comme « importantes » ou « critiques », sa propre documentation précise que toutes ne bénéficient pas nécessairement d’un correctif en temps réel.

KernelCare élimine toute incertitude en appliquant des correctifs en temps réel à toutes les vulnérabilités CVE du noyau, quel que soit leur niveau de gravité ; la couverture ne dépend donc pas de la note attribuée à une vulnérabilité CVE donnée.

La correction en temps réel devrait garantir la sécurité de l'ensemble du système sans nécessiter de redémarrage, mais kpatch n'intervient que sur le noyau. Toutes les vulnérabilités des bibliothèques de l'espace utilisateur, y compris les failles d'OpenSSL et de glibc à l'origine d'incidents tels que Heartbleed, GHOST et Looney Tunables, nécessitent toujours une mise à jour du paquet et un redémarrage du service ou de l'application. Ces bibliothèques sont à la base de presque tout ce que vous exécutez ; ainsi, un simple correctif de glibc ou d'OpenSSL peut impliquer le redémarrage d'une grande partie de la pile.

KernelCare comble cette lacune grâce à LibCare, qui applique des correctifs aux bibliothèques partagées telles qu’OpenSSL et glibc en mémoire, sans redémarrer les applications qui en dépendent. La possibilité d’appliquer des correctifs à des éléments critiques de l’espace utilisateur sans temps d’arrêt permet aux équipes de respecter les délais de mise en conformité aux normes PCI DSS, SOC 2 et FedRAMP sur des systèmes qui ne peuvent pas être mis hors ligne.

La mise à jour en direct devrait protéger tous les serveurs de votre parc, et pas seulement ceux équipés d'un processeur spécifique. kpatch prend en charge les mises à jour en direct sur les architectures x86-64 et ppc64le, ce qui laisse les systèmes Arm64 totalement dépourvus de cette fonctionnalité. À mesure que l'architecture Arm s'impose de plus en plus dans les centres de données et le cloud, cela constitue un angle mort de plus en plus préoccupant.

KernelCare prend en charge à la fois les architectures x86-64 et Arm64 ; ainsi, la même protection sans redémarrage s'applique, que la charge de travail s'exécute sur du matériel x86 traditionnel ou sur une plateforme Arm.

Les correctifs en temps réel devraient s'appliquer au noyau que vous utilisez actuellement, mais kpatch n'applique des correctifs qu'à un sous-ensemble d'entre eux. Il applique des correctifs en temps réel aux noyaux de base « errata » éligibles à kpatch, désignés par Red Hat une fois par trimestre ; ainsi, à moins que votre système n'utilise l'un de ces noyaux désignés, vous ne recevrez aucun correctif en temps réel tant que vous ne serez pas passé à l'un d'entre eux.

KernelCare n'impose aucune restriction d'éligibilité. Quel que soit le noyau chargé, il l'applique, de sorte que la couverture s'adapte à vos systèmes plutôt que de leur demander de se conformer à une liste.

Même lorsque vous utilisez un noyau éligible, la couverture est limitée dans le temps. Chaque noyau éligible reçoit des correctifs en temps réel pendant environ un an, après quoi vous devez mettre à jour le noyau et redémarrer pour continuer à bénéficier des correctifs. C'est cette limitation qui, sans crier gare, va à l'encontre de l'objectif visé. Au lieu de supprimer les redémarrages, kpatch ne fait que les reporter, et vous finissez de toute façon par planifier vos fenêtres de maintenance en fonction du calendrier du fournisseur.

KernelCare ne fixe aucune limite de ce type et continue à corriger chaque noyau pendant une durée pratiquement illimitée ; vous restez ainsi protégé sur votre noyau actuel, sans avoir à effectuer de redémarrage annuel obligatoire.

L'application des correctifs en temps réel devrait s'effectuer discrètement en arrière-plan, sans devenir une tâche supplémentaire à gérer. kpatch ne dispose pas d'agent dédié à l'automatisation des correctifs. Les correctifs sont fournis sous forme de paquets RPM que vous appliquez via yum ou dnf, ou que vous déployez à l'aide de Satellite. Cela signifie que la mise à jour reste soit une tâche administrative manuelle, soit une opération que vous mettez en place à l'aide d'outils de mise à jour polyvalents.

KernelCare installe un agent léger qui recherche et applique automatiquement les nouveaux correctifs, et s'intègre à votre solution d'automatisation informatique existante. Une fois déployé, la mise à jour des systèmes ne constitue plus une tâche fastidieuse et récurrente.

Red Hat ne fournit pas de correctifs « kpatch » en temps réel pendant la phase de prolongation de la durée de vie, et ce même avec le module complémentaire payant « Extended Life-cycle Support ». Une fois qu’une version arrive en fin de vie, vous n’avez plus accès aux correctifs en temps réel, même si vous continuez à payer pour les errata de sécurité.

KernelCare fait exactement le contraire. Il continue de fournir des correctifs en temps réel pour les versions de distributions en fin de vie telles que CentOS 7, Ubuntu 18.04, Debian 10, RHEL 7 et bien d’autres encore. Ainsi, les systèmes que vous ne pouvez pas mettre hors service dans les délais prévus restent protégés pendant que vous planifiez la migration selon votre propre calendrier.

Les correctifs appliqués à chaud doivent être réversibles, car il arrive parfois qu'un correctif doive être supprimé, par exemple lorsqu'une mesure de protection entraîne une perte de performances (comme ce fut le cas pour certains correctifs liés à Spectre et Meltdown) et qu'une autre solution est disponible.

kpatch n'en est pas capable. Pour annuler un correctif appliqué à chaud, il faut redémarrer le système, ce qui transforme un correctif problématique en une interruption planifiée et supprime l'avantage même qui rendait l'application de correctifs à chaud si intéressante. KernelCare, au contraire, vous permet de revenir en arrière sur n'importe quel correctif appliqué à l'aide d'une seule commande et sans redémarrage ; ainsi, l'annulation d'un correctif a un impact aussi faible que son application.

Certains environnements nécessitent un correctif que le fournisseur n'a pas encore mis à disposition, ou un correctif adapté à leur propre code. Avec kpatch, c'est à vous de vous en charger : vous créez vous-même le correctif à l'aide de kpatch-build, sans distribution gérée ni assistance technique. Pour la plupart des équipes, l'expertise requise en matière de noyau constitue un obstacle en soi.

KernelCare propose des correctifs personnalisés entièrement gérés, que TuxCare développe, teste et maintient pour vous. Vous bénéficiez ainsi du correctif dont vous avez besoin sans avoir à assumer la charge de travail ni les risques liés à la création en interne de correctifs en production.

À une échelle réelle, la mise à jour en direct doit être gérée de manière centralisée, et ce, de plus en plus souvent dans des environnements dépourvus d’accès à Internet. Avec kpatch, le déploiement centralisé implique la mise en place d’une instance de Red Hat Satellite disposant d’une licence distincte, ce qui représente un coût supplémentaire et un système de plus à gérer.

KernelCare inclut ePortal, un serveur de correctifs privé sur site permettant des déploiements par étapes, des déploiements contrôlés et la prise en charge de réseaux entièrement isolés physiquement, sans frais de licence supplémentaires. Cette fonctionnalité, qui fait l'objet d'un supplément chez Red Hat, est incluse dans l'offre de TuxCare.

Les opérations de correctifs modernes doivent pouvoir être automatisées par script et intégrées au reste de votre système d'automatisation. kpatch ne propose pas d'API native ; par conséquent, toute opération reposant sur une API passe à nouveau par Red Hat Satellite.

KernelCare intègre l'API ePortal pour l'enregistrement, la gestion et l'automatisation via Ansible, ce qui permet d'intégrer l'application de correctifs à chaud dans les pipelines existants sans avoir recours à un produit de gestion distinct.

Le choix d’un outil de correction est une décision à long terme ; la santé du projet est donc primordiale. Le projet open source en amont « kpatch » est désormais en mode maintenance, la création des correctifs étant désormais assurée par « klp-build » dans le noyau principal. KernelCare, en revanche, fait l’objet d’un développement actif et bénéficie d’un support commercial pour toutes les distributions et architectures, ce qui correspond exactement au type de trajectoire que l’on souhaite pour une infrastructure destinée à fonctionner pendant des années.

Lorsqu’une demande de correctif devient urgente, le délai de réponse est crucial. L’assistance 24 heures sur 24 proposée par kpatch est réservée aux cas de gravité 1 et 2 et n’est accessible qu’aux abonnés Premium ; les problèmes de moindre gravité doivent donc attendre les heures de bureau. KernelCare inclut une assistance en ligne disponible 24 heures sur 24, 7 jours sur 7 et 365 jours par an, quel que soit le niveau d’abonnement.

KernelCare Enterprise est proposé à partir de 50 $ par système et par an pour la correction en temps réel du noyau et fonctionne sur vos systèmes RHEL existants, sans nécessiter d’abonnement Red Hat. La correction en temps réel dans l'espace utilisateur pour OpenSSL et glibc est disponible via le module complémentaire LibCare. kpatch, en revanche, n'entraîne pas de frais supplémentaires mais s'appuie sur un abonnement RHEL actif, dont le prix est de 878,90 $ pour la version Standard ou de 1 428,90 $ pour la version Premium par système et par an, avec le module complémentaire EUS à 273,90 $ supplémentaires pour maintenir les fenêtres de correction en temps réel ouvertes.

L'écart est particulièrement flagrant à l'échelle d'un parc informatique. Avec KernelCare, les correctifs en temps réel du noyau pour 100 systèmes coûtent 5 000 dollars par an. Pour obtenir une solution équivalente via Red Hat, un abonnement RHEL Standard associé à l'EUS coûte près de 115 280 dollars par an, soit environ 23 fois plus. Et même si l’on considère que kpatch est déjà pris en charge au sein d’un parc RHEL existant, les droits EUS qui permettent de continuer à l’utiliser représentent tout de même un coût supplémentaire d’environ 27 390 $ par an.

Si vous n’utilisez que RHEL, kpatch peut sembler être un choix naturel, puisqu’il est inclus dans votre contrat Red Hat. L’intérêt de cette comparaison est de montrer que, même sur un parc exclusivement composé de RHEL, la configuration par défaut laisse plus de vulnérabilités non couvertes qu’il n’y paraît. De nombreuses vulnérabilités CVE du noyau et toutes celles de l'espace utilisateur ne sont pas corrigées ; la couverture offerte se limite aux noyaux de base sélectionnés par Red Hat ; chaque fenêtre de mise à jour expire au bout d'environ un an ; et même la réversion d'un correctif nécessite un redémarrage.

KernelCare a été conçu pour éliminer ces compromis. Il applique en continu des correctifs au noyau et à l'espace utilisateur, quel que soit le niveau de gravité, quel que soit le noyau que vous utilisez, et bien au-delà de sa fin de vie. Les restaurations s'effectuent sans redémarrage, les correctifs personnalisés sont entièrement gérés, et le tout fonctionne sur vos systèmes existants pour un coût bien inférieur à celui pratiqué par Red Hat. Ainsi, que vous utilisiez plusieurs distributions ou que vous souhaitiez corriger toutes les vulnérabilités sans interrompre le fonctionnement de vos systèmes, KernelCare est le choix le plus judicieux.

La migration de kpatch vers KernelCare est très simple. Un seul script de démarrage rapide suffit pour installer KernelCare ; vos systèmes bénéficient alors d'une mise à jour en temps réel et continue à tous les niveaux, tandis que vos charges de travail existantes continuent de fonctionner aussi longtemps que vous le souhaitez.

Pour les équipes qui souhaitent le découvrir en avant-première, KernelCare propose un essai gratuit de 30 jours avec toutes les fonctionnalités, afin que vous puissiez vous assurer d'une couverture ininterrompue avant de vous engager.