KernelCare ePortal pour les infrastructures d'hébergement de grande envergure

Intégrer KernelCare ePortal dans la gestion de flotte

KernelCare ePortal Il s'agit du composant de gestion et de distribution autonome destiné aux agents KernelCare dans les environnements Linux de grande envergure. Il regroupe les ensembles de correctifs, les flux et les clés de registre en un seul emplacement contrôlé. L'opérateur décide ainsi non seulement si les hôtes doivent recevoir des correctifs, mais aussi à partir de quelle source locale et selon quelle logique de validation cela doit se faire.

Sans ePortal, les agents communiquent directement avec l'infrastructure TuxCare. C'est généralement la solution la plus simple pour les parcs de serveurs de petite taille, relativement homogènes et connectés à Internet : il n'y a pas de plateforme centrale supplémentaire à mettre à jour, à sécuriser et à surveiller. Cependant, à mesure que le nombre de systèmes augmente, cette simplicité devient un inconvénient lorsqu'il est nécessaire de mettre en place des autorisations traçables ou de limiter les sorties réseau.

Au sein d'une flotte d'hébergement, on trouve souvent des serveurs web, des serveurs de bases de données, des hôtes de virtualisation et des systèmes de gestion utilisant différentes distributions et différentes séries de noyaux. Un élément central Achat de patchs permet d'alimenter ces groupes techniques de manière ciblée avec les flux et les clés appropriés. ePortal ne constitue donc pas une alternative à l'agent KernelCare, mais étend la récupération des ensembles de correctifs par ce dernier en y ajoutant un contrôle et une distribution au niveau local.

L'intérêt ne réside donc pas uniquement dans le nombre de serveurs. Les facteurs déterminants sont les cycles de correctifs obligatoires, les obligations de contrôle et de justification, les spécifications réseau, ainsi que la question de savoir si un service central peut lui-même fonctionner de manière fiable. Ces exigences déterminent également si une mise en miroir locale, une mise en cache ou un accès direct constitue l'architecture appropriée.

Distinguer le « live patching », KernelCare et LibCare

À l'adresse suivante : Patching en direct L'agent KernelCare vérifie régulièrement si des ensembles de correctifs adaptés sont disponibles. Il les télécharge, les vérifie et les installe dans le noyau en cours d'exécution. Les correctifs de sécurité peuvent ainsi être activés sans qu'un redémarrage du noyau soit nécessaire pour cette étape. Les ensembles de correctifs applicables dépendent du noyau installé et de la distribution prise en charge.

KernelCare désigne l'offre de correctifs en temps réel pour le noyau. Il convient de distinguer LibCare de cette offre : il s'agit d'un produit complémentaire optionnel destiné à certains composants de l'espace utilisateur, et non d'un autre nom pour désigner les correctifs du noyau. ePortal, quant à lui, n’applique pas lui-même de correctifs au noyau, mais gère les ensembles de correctifs, les flux et l’enregistrement des agents KernelCare au sein d’une installation d’entreprise locale.

L'ancienne appellation « KernelCare Plus » ne devrait apparaître que dans le cadre du classement de documentations plus anciennes. Le fabricant a arrêté la commercialisation de ce produit depuis mars 2023 et l’a remplacé par KernelCare. Pour les inventaires, il est donc important de ne pas assimiler les agents installés, les contrats et la documentation aux composants ou aux fonctionnalités actuels en se basant sur les anciens noms de produits.

Le « live patching » ne remplace pas un processus de maintenance complet. Prévu Redémarrages Elles restent nécessaires, par exemple, pour les changements réguliers de noyau, les mises à jour matérielles et logicielles, les modifications de pilotes, les travaux de configuration ou les cas de défaillance qui ne peuvent pas être résolus en temps réel. Un plan d’exploitation devrait donc combiner la réduction de l’exposition grâce à des ensembles de correctifs avec le maintien de créneaux de redémarrage planifiés, plutôt que de les supprimer sans les remplacer.

Quand la gestion centralisée des correctifs est-elle rentable ?

ePortal est la solution idéale lorsque l'entreprise doit non seulement déployer rapidement des correctifs, mais aussi contrôler de manière rigoureuse leur mise en place. Cela concerne, par exemple, les groupes de validation distincts pour les hôtes Canary, l'environnement de test et la production, les règles restrictives de pare-feu sortant ou les justificatifs indiquant quel hôte était affecté à quel flux. De nombreux systèmes utilisant différentes plateformes tirent également profit d’une instance de distribution gérée de manière centralisée.

La valeur ajoutée doit justifier l'investissement. Une instance ePortal nécessite de la capacité, des mises à jour, des sauvegardes, une protection des accès et une surveillance ; en cas de haute disponibilité, il faut y ajouter la réplication et l'architecture réseau. Pour un petit nombre de serveurs homogènes disposant d’un accès Internet autorisé, l’accès direct via l’infrastructure TuxCare reste donc souvent plus simple. Un nombre réduit de composants signifie dans ce cas une empreinte opérationnelle propre plus faible.

D'un point de vue économique, la gestion centralisée s'avère particulièrement utile lorsque des opérations simultanées non planifiées seraient coûteuses : par exemple, dans le cas de nombreux serveurs web clients, de clusters de bases de données ou d'hôtes de virtualisation. Un Processus de validation Cela permet alors de prendre en compte à la fois les similitudes techniques et les risques commerciaux. Les groupes ne devraient pas être créés uniquement en fonction de l'emplacement, mais devraient également tenir compte de la distribution, de la version du noyau, de l'hyperviseur, du panneau de configuration, du matériel et du profil des clients.

Il ne faut toutefois pas surestimer la portée de cette protection. KernelCare ne fournit en principe des correctifs en temps réel pour un noyau que tant que le fournisseur de la distribution publie des mises à jour de sécurité pour la série de noyaux concernée. De plus, l'application de correctifs en temps réel ne constitue pas une garantie absolue que toutes les vulnérabilités ont été corrigées. L'état des correctifs, la prise en charge par la distribution et la maintenance régulière doivent être vérifiés séparément.

La décision opérationnelle ne se résume donc pas à un principe général selon lequel „ la centralisation est préférable “. ePortal s’avère pertinent lorsque le contrôle local, la répartition par niveaux et une traçabilité fiable répondent à des exigences concrètes. En l’absence de ces exigences, l’approvisionnement direct, délibérément simple, peut s’avérer plus robuste. À l’étape suivante, c’est le modèle de mise à disposition souhaité qui détermine les besoins en stockage et les dépendances externes.

Choisir correctement la mise en miroir et la mémoire cache

Le choix du modèle de distribution détermine le degré d'autonomie d'un parc d'hébergement en matière de récupération des correctifs, ainsi que l'infrastructure qu'il doit mettre en œuvre à cette fin. Dans le cas d’un téléchargement direct, les agents KernelCare téléchargent les ensembles de correctifs via l’infrastructure TuxCare. ePortal, en revanche, délocalise la validation, la mise à disposition locale et la distribution vers une instance dédiée ; celle-ci peut répliquer les ensembles de correctifs sous forme d’archives complètes ou filtrées, ou les mettre en cache en fonction des besoins.

Une mise en miroir complète est utile lorsque les ensembles de correctifs déjà transférés doivent rester disponibles localement même en cas d’interruption de la connexion externe, ou lorsque des autorisations internes contraignantes l’exigent. Une mise en miroir filtrée limite la taille des archives et le trafic de données aux distributions effectivement utilisées. Pour cela, l’inventaire doit recenser de manière fiable les séries de noyaux et les architectures utilisées par le parc informatique ; sinon, une archive fera défaut précisément au moment où un hôte en aura besoin.

Le Mode cache Cela permet d'économiser de l'espace de stockage, mais ne signifie pas pour autant que le système fonctionne de manière totalement isolée. ePortal charge les métadonnées et récupère les fichiers binaires de correctifs auprès de la source si nécessaire ; selon la documentation, les fichiers binaires téléchargés restent dans le cache local pendant deux semaines. Cela peut suffire pour les réseaux d’agents cloisonnés, à condition qu’ePortal soit autorisé à utiliser le chemin montant autorisé.

Un serveur ePortal fonctionnant en mode « air-separated » doit être considéré séparément. Les nouvelles archives de correctifs doivent alors être intégrées via un transfert manuel planifié séparément. À cette fin, définissez la vérification des sources, le contrôle d’intégrité et de signature, le partage des supports ou du réseau, l’ordre d’importation et les responsabilités. Ni la mise en miroir filtrée ni la mise en miroir complète ne génèrent automatiquement ce processus ; elles déterminent uniquement quelles archives ePortal conserve localement.

La planification du stockage ne doit pas se limiter à la taille actuelle des archives. TuxCare recommande, à titre indicatif, pour ePortal, un stockage SSD offrant au moins 100 IOPS ainsi qu'une croissance d'environ 4 à 5 GiB par mois. Ces spécifications du fabricant ne remplacent en aucun cas une planification de la capacité : les objectifs de récupération, les déploiements parallèles, les latences réseau, le nombre de variantes de noyau et les exigences en matière de surveillance peuvent influencer l'architecture davantage que la capacité disponible sur disque.

Mettre en place des anneaux de raccordement pour les parcs de serveurs d'hébergement

Les cycles de déploiement permettent de mettre en œuvre un déploiement contrôlé à partir d'un ensemble de correctifs disponible au niveau central. Un petit groupe « canary » reçoit le correctif en premier, suivi de l'environnement de test, puis d'un groupe de production restreint, et enfin de l'ensemble de la production. Chaque anneau nécessite des observations prédéfinies et un responsable ; sans ces critères, un report ne fait que repousser le risque au lieu de l'évaluer.

Pour les anneaux de production, Stable le canal prévu. Le canal « Testing » se prête à un processus d'évaluation distinct et délibérément contrôlé, car il intègre tous les ensembles de correctifs disponibles et peut donc contenir des ensembles de correctifs supplémentaires qui ne sont pas encore marqués comme « Stable ». Selon la documentation, le canal « Unstable » est un canal d'accès anticipé et n'est pas recommandé. Les canaux « Testing » et « Unstable » ne doivent donc pas être considérés comme des environnements de production généraux.

Les anneaux doivent être constitués en fonction de leurs similitudes techniques, et non uniquement en fonction de l'emplacement du centre de données. Les critères pertinents sont la distribution et la série de noyaux, la plate-forme matérielle, la virtualisation, le panneau de contrôle, la pile de serveurs web et le profil client. Un hôte « canary » utilisant une autre série de noyaux ou un autre type de virtualisation ne reflète que de manière limitée le comportement d’un système cible en production. Dans le cas de l’hébergement mutualisé, les profils de ressources et les configurations du Gestionnaires LVE de CloudLinux dans cette évaluation, car ils peuvent influencer les profils de charge et les profils de défaillance.

Une attention particulière doit être portée aux nouvelles instances d'ePortal. Selon les indications du fabricant, ePortal vérifie toutes les dix minutes la présence de nouveaux ensembles de correctifs et les télécharge, mais ne les met pas automatiquement à disposition dans chaque flux. Lorsque les archives sont chargées pour la première fois, les ensembles de correctifs qu'elles contiennent se voient attribuer la même date de publication. Un délai déjà configuré peut donc entraîner le transfert de l'ensemble du stock initial vers un flux mis à jour automatiquement une fois ce délai écoulé.

Pendant la synchronisation initiale, suspendez donc la mise à jour automatique des flux de production et l'affectation de leurs clés de production. Chargez l'ensemble initial dans son intégralité, vérifiez-le ainsi que la configuration des flux, puis attribuez les clés aux anneaux prévus de manière contrôlée ou activez leur mise à jour automatique. La logique de temporisation s'applique ensuite aux nouveaux ensembles de correctifs ; elle ne permet pas de séparer de manière fiable le stock initial historique d'une nouvelle instance.

Séparer les flux, les clés et les mandants

Les flux représentent l'aspect technique des anneaux de déploiement : ils relient le canal de patch et la logique de temporisation à un groupe de systèmes. Les clés d'enregistrement peuvent être associées à des flux et soumises à des limites de serveur. Cela permet par exemple à un opérateur de fournir à des plateformes internes, à des offres de serveurs gérés et à des environnements clients distincts des chemins de déploiement différents, sans avoir à modifier individuellement la configuration des agents sur chaque hôte.

Cette affectation ne constitue toutefois pas une limite de sécurité exhaustive. La fonction optionnelle Unités opérationnelles prend en charge la multi-location dans l'ePortal, mais ne remplace ni la segmentation du réseau, ni un modèle d'autorisation, ni la séparation des responsabilités administratives. De même, la journalisation, la gestion des secrets et la vérification des personnes autorisées à créer des clés ou à modifier des flux doivent être planifiées et contrôlées régulièrement, indépendamment de la fonctionnalité du produit.

Dans les environnements multi-clients, la séparation entre la gestion des correctifs et le reste de l'isolation de l'hébergement revêt une importance particulière. Une clé peut limiter l'affectation prévue des flux et le nombre de serveurs enregistrables, mais elle n'empêche pas les accès croisés dans d'autres composants de l'infrastructure. L'isolation des processus et du système de fichiers reste une tâche distincte ; à ce sujet, l'article sur CloudLinux SecureLVE au niveau des comptes et des sites web.

À partir de la version 2.14-1 d'ePortal, les clés API peuvent être utilisées pour l'API publique à la place de l'authentification de base. L'administration d'ePortal permet notamment de créer des clés API pouvant être révoquées individuellement et de définir une date d'expiration facultative. Cela facilite la mise en place d'autorisations distinctes pour les connexions à la CMDB ou l'automatisation de la configuration, à condition que les droits du compte utilisateur correspondant soient délibérément limités.

Enregistrez les jetons en tant que secrets dans un système de gestion des secrets, et non dans des playbooks, des images, des historiques de shell ou des tickets. Il s'agit d'une mesure de sécurité opérationnelle et non d'une propriété automatiquement imposée par ePortal. Un processus pratique attribue à chaque clé un propriétaire, un objectif, des produits autorisés, une limite de serveurs et une date de rotation.

Les clés API doivent être révoquées de manière ciblée en cas de changement de système, de changement de rôle ou lorsque l'accès à l'automatisation n'est plus nécessaire. Les clés d'enregistrement sont traitées différemment : selon la documentation, la suppression d'une telle clé entraîne également la suppression de tous les serveurs enregistrés sous celle-ci dans ePortal. Avant de la supprimer, prévois donc la migration vers une nouvelle clé ou le réenregistrement des hôtes concernés, puis vérifie leur attribution de flux ainsi que leur statut d’enregistrement.

Assurer un fonctionnement fiable de la réplication et du protocole TLS

Pour une distribution de correctifs à haute disponibilité Plusieurs nœuds ePortal sont combinés de manière à ce que les agents KernelCare s'adressent à un nom DNS de cluster commun ou à un équilibreur de charge HTTP. Pour les tâches administratives, vous utilisez en revanche un point de terminaison d'administration contrôlé et spécifique à chaque nœud. Selon le fabricant, vous ne devez pas utiliser le point de terminaison commun du cluster pour les opérations dans l'interface d'administration d'ePortal.

Avant la mise en production, l'architecture ne doit pas se limiter à prendre en compte la défaillance d'un serveur ePortal. Il convient également de tenir compte de la résolution DNS, de l'équilibreur de charge, des certificats, de l'espace de stockage pour les archives de correctifs, de la connexion à la source des correctifs et de l'accessibilité depuis chaque segment de réseau. Un deuxième nœud dépourvu d'une surveillance coordonnée du réseau et des opérations n'améliore la disponibilité que de manière limitée ; en cas de panne, il peut même masquer des anomalies.

Les nœuds synchronisent les modifications par réplication. Cette synchronisation n'est pas nécessairement visible immédiatement. En particulier avec l'algorithme Round-Robin, un agent qui vient d'être enregistré peut d'abord atteindre le premier nœud pour l'enregistrement, puis, immédiatement après, un nœud qui n'est pas encore synchronisé pour la mise à jour. Les automatisations devraient donc prévoir un court délai d'attente ou une logique de réessai avec un nombre limité de tentatives, plutôt que de considérer une récupération immédiate du correctif comme un état final fiable.

Les coupures prolongées font également partie des scénarios de défaillance. Selon la documentation, les protocoles de réplication sont conservés pendant sept jours ; si un nœud reste déconnecté plus longtemps, il risque de passer à côté de certaines modifications. Le retard de réplication Il s'agit donc d'un état opérationnel, et non d'une simple valeur de diagnostic. Après des perturbations réseau, tu dois donc vérifier les affectations de flux, le stock de clés et les archives de correctifs sur le nœud qui revient en service, avant qu'il ne reprenne le traitement normal des requêtes des agents.

La réplication s'effectue via HTTP. En l'absence d'un protocole TLS approprié, les données de réplication sont donc transmises en clair. Segmentez ce trafic au moins vers un réseau de confiance ou mettez en place un protocole TLS adapté à l'architecture. Pour les points de terminaison d'agents accessibles depuis l'extérieur ou entre réseaux, une chaîne de certificats vérifiable constitue un élément essentiel de la Terminaison TLS; la désactivation de la vérification des certificats ne constitue pas une solution durable acceptable.

Si un proxy inverse est placé en amont d'ePortal, les noms d'hôte autorisés doivent être configurés afin qu'ePortal limite les requêtes d'en-tête d'hôte. Le proxy doit également transmettre correctement l'en-tête d'hôte d'origine ainsi que l'en-tête X-Forwarded-Proto. Dans le cas contraire, cela peut entraîner des URL externes erronées, des problèmes de redirection ou une identification incorrecte du protocole utilisé. Cette configuration des en-têtes doit donc faire partie intégrante de toute modification du proxy et de sa validation.

Mettre en place des procédures de vérification, de sauvegarde et de surveillance

Un correctif en direct contrôlable nécessite des vérifications régulières, et pas seulement une première installation réussie. Enregistrez au minimum l'affectation de flux de chaque hôte, la dernière validation de l'agent, l'état des correctifs signalé et l'état des clés de registre. Complétez ces données en indiquant les équipes responsables et une décision de validation traçable. Cela permet, en cas d'alerte de sécurité, de déterminer précisément quel groupe utilise quel canal de déploiement.

D'autres contrôles réguliers portent sur la croissance du stockage, l'espace libre pour les archives, l'état de la réplication, ainsi que la rotation ou la révocation des clés qui ne sont plus nécessaires. Les clés API sont plus adaptées aux requêtes automatisées que les mots de passe administrateur partagés, car elles peuvent être gérées individuellement, révoquées et, si nécessaire, dotées d'une date d'expiration. À titre de mesure de sécurité opérationnelle, enregistrez-les dans un gestionnaire de secrets, et non dans des images, des playbooks ou des tickets.

Pour un cluster existant, l'appel de test non modificatif suivant constitue un élément approprié pour la surveillance ou un contrôle d'intégrité planifié. Il fournit un statut succinct lisible par machine, incluant le retard de réplication. En cas de problème, l'appel se termine avec le code de sortie 1 ; le système de surveillance doit signaler cet état, mais également en déterminer la cause de manière plus précise à l'aide des données relatives aux nœuds et au réseau.

kc.eportal replication --short-status

ePortal fait la distinction entre une sauvegarde d'archives et une simple sauvegarde de base de données. La syntaxe complète de la commande est la suivante : kc.eportal backup <path_to_archive>; elle crée une archive de sauvegarde comprenant les fichiers de correctifs. Avec kc.eportal backup-db <path_to_backup> En revanche, vous ne sauvegardez que les bases de données sans les fichiers de correctifs. Cette deuxième méthode convient aux données de configuration et aux données du serveur, mais pas à l'archivage local des correctifs.

Ces sauvegardes de l'ePortal ne couvrent pas automatiquement l'ensemble de l'environnement. La configuration du système d'exploitation, celle du proxy inverse et de l'équilibreur de charge, les certificats TLS et les clés privées, les paramètres DNS ainsi que les configurations externes de pare-feu ou de gestion des secrets nécessitent des règles de sauvegarde et de restauration spécifiques. Pour chaque type de sauvegarde, définissez l’objectif, la durée de conservation, l’emplacement de stockage et la procédure de restauration applicable.

Lors d'une restauration, le service ePortal doit être arrêté. Planifiez cette interruption de service, informez si nécessaire les équipes opérationnelles concernées, puis vérifiez de manière ciblée la cohérence des données ainsi que l'accessibilité pour les agents. Une sauvegarde n'est considérée comme effective qu'après une planification contrôlée Sauvegarde comme fiable. Un test ne doit en aucun cas modifier par inadvertance des flux de production ou des attributions de clés.

Évaluer les symptômes de défaillance et prendre une décision opérationnelle

Si les correctifs attendus ne sont pas disponibles, il convient dans un premier temps de distinguer entre une indisponibilité, un échec de téléchargement et une absence de validation. Vérifiez la version installée de l'agent et de l'ePortal, la clé et le flux associés, la distribution appropriée ainsi que la série de noyaux, et enfin la connexion à la source des correctifs. Un correctif peut également manquer si la série de noyaux concernée ne bénéficie plus de mises à jour de sécurité de la part du fournisseur de la distribution ; le « live patching » ne lève pas cette limitation.

Les notes historiques du fabricant concernant d'anciennes versions de composants ne doivent pas être considérées comme des spécifications de version définitives. Une note datant de décembre 2025 concernait notamment KernelCare-Agent 3.x et ePortal 2.20 dans le cadre d'un nouveau format de correctif signé. Avant toute mise à jour, vérifie donc la version actuelle Matrice de compatibilité, les versions effectivement installées et l'ordre de mise à jour validé en interne.

En mode cache, une absence de cache (cache miss) associée à un accès externe restreint peut retarder le téléchargement du correctif, car le fichier binaire requis n'est pas encore disponible localement. Cela ne prouve pas pour autant que le système fonctionne de manière totalement isolée. Pour les zones à accès restreint, définissez quelles connexions sont autorisées, comment les archives manquantes sont transférées et qui est responsable de l'autorisation, de l'intégrité et du moment de ce transfert.

Un autre type d'erreur consiste en un déploiement inopinément étendu après le premier téléchargement d'archives de correctifs sur une nouvelle instance. Étant donné que les archives téléchargées pour la première fois apparaissent simultanément dans la logique de délai, un délai défini au préalable ne protège pas de manière fiable contre un déploiement simultané. Suspendre les mises à jour automatiques des flux et les mappages de clés en production pendant la synchronisation initiale, vérifier l'état initial, puis n'activer les anneaux de production qu'ensuite, de manière contrôlée.

Les écarts de réplication suite à une interruption prolongée d'un nœud et les proxys inversés défectueux nécessitent des mesures différentes : les premiers exigent une synchronisation de l'état du nœud, les seconds une vérification du protocole TLS, des noms d'hôtes autorisés ainsi que des en-têtes transmis. Ces deux cas doivent figurer dans des guides d'intervention prévoyant une procédure d'escalade claire. Un redémarrage systématique ne résout ni le problème des données manquantes ni celui d’une limite de confiance incorrecte.

ePortal s'avère particulièrement utile lorsque des cycles de correctifs, une distribution locale, des sorties réseau contrôlées ou des validations vérifiables sont réellement nécessaires. Pour un parc de serveurs restreint, homogène et connecté à Internet, le téléchargement direct via l'infrastructure TuxCare reste souvent plus simple. La décision doit donc mettre en balance la charge opérationnelle supplémentaire avec les obligations concrètes de contrôle et de justification, et non pas uniquement avec le nombre de serveurs.