Blog

You are currently viewing Architecture, dépôts, patchs, licences et conformité avec Red Hat Satellite

Architecture, dépôts, patchs, licences et conformité avec Red Hat Satellite

Premier article de la série introduite dans Cas concret d’industrialisation d’un parc mixte de VMs RHEL et Windows, celui-ci se concentre sur Red Hat Satellite, un outil central de l’infrastructure qui permet de gérer la mise à disposition des dépôts de packages (Red Hat et autres éditeurs logiciels), les patchs/errata (security/bugfix/enhancement) et la conformité des VMs via les outils intégrés OpenSCAP et Red Hat Insights.

Red Hat Satellite dans sa version 6.X a connu une refonte complète par rapport à la version 5.X basée sur le projet upstream Spacewalk. La version majeure 6 de Satellite est à présent basée sur plusieurs projets upstream qui vont assurer chacun une fonctionnalité et qui sont intégrés ensemble sous l’interface graphique exposée par Satellite :

  • Foreman gère le provisionement et le cycle de vie des systèmes. Il configure les systèmes avec, par exemple, kickstart ou des modules Puppet.
  • Katello gère les dépôts de packages et leur souscription par les systèmes, et permet de définir différentes versions de ces contenus (Content Views) et de les appliquer de manière ciblée aux systèmes via les étapes définies dans un cycle de vie.
  • Candlepin gère les souscriptions (licences) des systèmes.
  • Pulp s’occupe de la gestion du contenu des dépôts.
  • Puppet Master, intégré à Foreman, permet de configurer les systèmes.

Les fonctionnalités de Satellite sont également accessibles via une CLI (Command Line Interface) nommée Hammer qui permet d’accéder aux mêmes fonctionnalités que l’interface graphique, à quelques exceptions près. Hammer est très pratique pour automatiser l’intégration des OS dans Satellite lors de la création ou de la suppression de VMs.

Il y a également une API REST pour accéder aux fonctionnalités de Satellite. Je ne l’ai pas utilisée, je ne connais donc pas son périmètre de couverture par rapport aux fonctionnalités proposées par l’interface graphique.

Architecture

Le changement radical de l’architecture de Satellite et l’intégration de plusieurs projets upstream dans un même outil a mené à quelques soucis qui se résorbent au fil des versions 6.X. Pour préciser, je travaille actuellement avec un Satellite 6.3, qui est arrivé en fin de support Red Hat Satellite Product Life Cycle, et travaille également sur son upgrade en version 6.6. Red Hat met à disposition un outil pratique qui, en fonction d’un certain nombre de paramètres de notre installation existante, va donner la procédure détaillée à appliquer pour upgrader Satellite d’une version à une autre : Red Hat Satellite Upgrade Helper. A noter que la mise à jour ne peut se faire directement de 6.3 à 6.6, mais nécessite un chemin d’upgrade progressif 6.3 à 6.4, puis 6.4 à 6.5 et finalement 6.5 à 6.6.

Concernant l’architecture, la multiplicité des technologies sous-jacentes a généré des lenteurs, notamment le stockage des données (hors contenu lui-même) : il se répartit, en 6.0, entre ElasticSearch, MongoDB et PostgreSQL. ElasticSearch a été retiré en version 6.2 de Satellite pour améliorer les performances. Red Hat envisage également de migrer la persistance des données de MongoDB vers PostgreSQL (Red Hat Satellite to standardize on PostgreSQL backend). Cependant, MongoDB est encore nécessaire à l’heure actuelle. A noter également que depuis le rachat de Ansible par Red Hat, Ansible est de plus en plus présent dans la gamme de produits fourni par Red Hat et Satellite ne déroge pas à cette règle, il est d’ailleurs envisagé de remplacer Puppet par Ansible. Ce remplacement, comme celui de MongoDB, n’est pas encore finalisé.

Concernant la haute disponibilité des services de Satellite, jusqu’à la version 6.2 de Satellite, une architecture est proposé, basée sur HA-LVM (Highly Available LVM) en actif/passif avec Pacemaker en gestionnaire de ressources, ainsi que des Capsules accessibles derrières un HAProxy. A partir de Satellite 6.3, cette architecture HA n’est plus d’actualité : la méthode conseillée est depuis d’utiliser un Satellite et des Capsules virtualisés (VMs) et de se baser sur les mécanismes de HA proposés par l’hyperviseur. Il semblerait que les retours des clients sur l’architecture de référence précédente (jusqu’à la version 6.2 de Satellite) n’étaient pas positifs. Il est vrai que la configuration était quelque peu complexe.

Au plus près des ressources !

Les capsules quant à elles permettent de mettre à disposition le contenu (les packages) au plus près des VMs (OS) clientes. En effet, on peut voir le Serveur Satellite lui-même comme un « proxy » qui a accès à Internet et met à disposition « en interne » dans votre réseau les packages téléchargés depuis le CDN de RedHat pour éviter que chaque VM cliente n’ait besoin d’un accès Internet et télécharge les packages pour son usage propre (imaginez la bande passante nécessaire pour un parc de plusieurs milliers de VMs !). Une fois tout le contenu des dépôts téléchargé sur le serveur « Proxy » Satellite, des Content Views (détails dans la suite de l’article) sont créées et une gestion fine de l’exposition des dépôts/packages aux VMs clientes est mise en place. Imaginez maintenant que votre infrastructure interne soit elle-même découpée sur plusieurs datacentres éloignés géographiquement : de même que Red Hat met à disposition ses packages via un CDN au plus proche des utilisateurs, vous allez mettre les Content Views et autres services de Satellite que vous avez soigneusement préparés/configurés au plus près des VMs clientes de votre infrastructure interne. C’est l’utilité des capsules ! L’avantage est évidemment la réduction de la consommation de la bande passante interne et des temps de chargement. Autre élément important, la multiplication des capsules dans un même datacentre peut également être un facteur de répartition de charge en distribuant les OS/VMs clients de Satellite entre les différentes capsules. La capsule permet également une amélioration de la disponibilité du service lors d’opérations de maintenance sur le serveur Satellite. A noter que le serveur Satellite dispose lui-même par défaut d’une capsule interne.

Gestion des licences

Pour réaliser cette association de licences aux ESX et pour savoir sur quel ESX s’exécute quelle VM (pour savoir si elle peut bénéficier de la licence « guest »), Satellite doit avoir accès à des informations détenues par le vCenter. Un autre élément d’architecture, non décrit précédemment, est alors nécessaire pour la gestion des licences : la liste des ESX et des VMs qui s’exécutent « dessus » devra être récoltée par l’agent virt-who (via un appel à l’API exposée par vCenter qui a connaissance des ESXi) pour ensuite les enregistrer dans Satellite (à nouveau via API). L’agent virt-who peut très bien s’exécuter sur la même VM que Satellite, si votre configuration réseau le permet pour l’accès à l’API du vCenter. Satellite possède dans son IHM un module permettant de générer la configuration pour virt-who à partir d’informations de connexion que vous saisissez. Attention, il est possible de filtrer les ESX à prendre en charge (récolter) par virt-who via une blacklist (exclusion) ou une whitelist (inclusion) : cela est très intéressant pour limiter les coûts en licences en réservant, par exemple, certains ESX à l’exécution de Windows.

Une fois les ESX (et la correspondance des VMs) enregistrés dans Satellite. Il faut associer les licences aux ESX. Pour ce faire, rendez-vous sur le portail Red Hat dans la section Allocations d’abonnement et créez une nouvelle allocation correspondant à votre serveur Satellite. A l’intérieur de cette allocation, vous ajoutez les abonnements dont vous souhaitez déléguer la gestion à Satellite. Une fois cela fait, vous pouvez télécharger une archive depuis le portail que vous chargez ensuite dans Satellite via une fonctionnalité de l’interface graphique. Le nombre de souscriptions déléguées est décompté de celles disponibles sur le portail et créditées dans Satellite. C’est aussi simple que cela.

Il reste un type de licence dont nous n’avons pas parlé : les Red Hat Satellite Infrastructure Subscription. Elles sont générées automatiquement (50 par défaut) à la prise de licences Smart Management donnant accès à Satellite. Ces licences permettent d’enregistrer les serveurs de l’infrastructure Satellite : le serveur Satellite lui-même et ses capsules. J’en laisse donc une partie sur le portail et en délègue une partie à Satellite.

Sur le portail Red Hat, apparaîtra (dans les systèmes) le serveur Satellite que vous avez enregistré directement sur le portail et auquel vous avez attaché un abonnement Red Hat Satellite Infrastructure Subscription laissé disponible sur le portail. Si vous créez un « clone » Satellite (via la commande satellite-clone), dans le cadre de qualification de changements, vous enregistrerez également ce serveur directement sur le portail Red Hat avec le même abonnement.

Gestion des Content Views

C’est la fonctionnalité centrale de Satellite.

Une Content View est un ensemble de packages exposés aux VMs. Ces packages sont issus des dépôts ajoutés dans la Content View et auxquels ont a appliqué des filtres (date, nom de package ou d’erratum, …). On peut ainsi définir précisément ce qui sera exposé aux VMs.

Lorsque l’on est satisfait de la Content View que l’on a créée, on la publie, ce qui aura pour effet de créer la version 1.0 de cette Content View et de mettre cette version à disposition dans l’environnement Library. L’environnement Library est la première étape du Lifecycle (cycle de vie) des Content Views (ou pour être plus précis, des versions des Content Views). Puis au fur et à mesure des tests et validations de la version de la Content View publiée, on la promeut pour l’exposer aux environnement suivants.

Une VM est associée à une Content View ET à un environnement Satellite. Voici quelques environnements classiques : Library, Development, Hors Prod 1, Hors Prod 2, Pre Production, Production. En fonction de la criticité de la VM, elle est affectée à un environnement Satellite.

Le couple Content View ET environnement Satellite permet d’exposer une version donnée de la Content View à une VM, donc d’exposer un ensemble de packages et errata filtrés issus de dépôts.

A noter qu’un erratum (des errata ? ) est un regroupement de packages qui répondent, une fois appliqués, à une ou plusieurs problématiques soulevées par une ou des CVE (Common Vulnerabilities and Exposures) ou bien remontées par l’outil de gestion de bugs/demandes de Red Hat.

Vous pouvez consulter les Red Hat Product Errata.

Par exemple :

RHSA-2020:0100 – Security Advisory :

Synopsis – Important: kernel-rt security and bug fix update

Description – The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

  • kernel: Use-after-free in __blk_drain_queue() function in block/blk-core.c (CVE-2018-20856)
  • kernel: TLB flush happens too late on mremap (CVE-2018-18281)
  • kernel: fix race condition between mmget_not_zero()/get_task_mm() and core dumping (CVE-2019-11599)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Bug Fix(es):

  • update the MRG 2.5.z 3.10 realtime-kernel sources (BZ#1779367)

Le patch management

En pratique, une équipe produit/publie régulièrement une nouvelle version d’une Content View, la teste dans un environnement Satellite de criticité basse (Developpement par exemple), puis la promeut dans l’environnement suivant par ordre de criticité (Hors Prod 1 dans notre exemple). L’équipe en charge des serveurs met à jour (yum update) les VMs associées à l’environnement Hors Prod 1. Ensuite une période de tests par les projets est respectée avant promotion de cette version de Content View en Hors Prod 2 et mise à jour des VMs associées à l’environnement Hors Prod 2. Et ainsi de suite jusqu’en Production. Les VMs sont ainsi régulièrement sécurisées/corrigées/améliorées.

Evidemment, il est possible d’appliquer unitairement un erratum en particulier (soit via yum sur une VM unique, ou bien sur un groupe de VMs via Satellite) pour répondre rapidement à une faille de sécurité critique/importante qui vient d’être découverte et pour laquelle un erratum a été promptement mis à disposition.

Les Content Views composite

Une Content View Composite est une « vue chapeau » qui va rassembler plusieurs versions de Content Views plutôt que directement des dépôts et des packages. Elle permet d’accélérer/faciliter la mise à disposition de packages issus de dépôts ayant des fréquences de mise à jour différentes.

Prenons l’exemple d’une Content View RHEL7 WebApp qui expose, dans sa version 3.0 (par exemple), à la fois les packages des dépôts « Red Hat Enterprise Linux 7 Server RPMs x86_64 » et « remi-php72 » : les fréquences de mise à jour de ces 2 dépôts sont très différentes. Je ne peux pas mettre à disposition les nouveaux packages du dépôt « remi-php72 » dans une nouvelle version (4.0) de la Content View sans embarquer également les nouveaux packages du dépôts « Red Hat Enterprise Linux 7 Server RPMs x86_64 » si celui-ci a été synchronisé depuis « Internet » depuis la publication de la dernière version de la Content View.

A présent, je mets les packages du dépôt « Red Hat Enterprise Linux 7 Server RPMs x86_64 » dans une Content View RHEL7 et les packages du dépôt « remi-php72 » dans une Content View WebApp, puis que je transforme (re-crée) la Content View RHEL7 WebApp comme une Content View composite qui embarque les versions 1.0 de la Content View RHEL7 et 1.0 de la Content View WebApp. 

Je peux à présent produire et publier une version 2.0 de la Content View WebApp, puis une version 2.0 de Content View composite RHEL7 WebApp qui expose les contenus de la version 1.0 de la Content View RHEL7 et de la version 2.0 de la Content View WebApp.

La Content View composite RHEL7 WebApp permet de mettre à disposition uniquement les mises à jour de « remi-php72 » via l’intégration de la nouvelle version de la Content View WebApp, sans pour autant changer la version (et donc le contenu) de la Content View RHEL7. Cela permet de se concentrer uniquement sur les nouveautés du ou des dépôts PHP de la Content View WebApp, et donc d’éviter de devoir tester/valider les nouveautés de l’intégralité des dépôts.

Ce type de Content View permet d’améliorer la vélocité de la mise à disposition de packages.

Contrôle de conformité

Le contrôle de conformité est une des fonctionnalités intéressantes proposées par Satellite. Ce contrôle de conformité est rendu possible via 2 outils distincts intégrés dans Satellite.

Le premier est OpenSCAP : il permet de jouer un ensemble de règles/vérifications regroupées dans des Security Policies (Choosing a Policy / Security policies available in the SCAP Security Guide) correspondant à différents niveaux de sécurité et à différentes réglementations, fonction de l’emploi que vous faites des OS, par exemple :

Vous pouvez également, à partir de ces définitions, ajouter des règles spécifiques à votre entreprise ou en retirer via des tailoring files. Il est ensuite possible de configurer sur quels groupes de VMs appliquer quelles règles dans votre parc, selon une fréquence à paramétrer. Vous obtiendrez ainsi des rapports de conformité réguliers sur vos VMs qui vous donneront des indicateurs sur la conformité de votre parc au regard de vos attentes.

Le second outil est Red Hat Insights : il fonctionne sur le même principe que OpenSCAP, sauf que vous ne paramétrez pas les règles, ce sont des règles Red Hat qui se basent sur leur knowledge base pour vous conseiller les actions à effectuer sur vos VMs, essentiellement au regard des CVE (Common Vulnerabilities and Exposures).

Frédéric FAURE

 

Étiquettes : , , , , , , , , , , , , , , , , , , , ,

Laisser un commentaire