Canonical corrige les échecs des conteneurs FIPS sur les noyaux Kubernetes mainline

Canonical a publié des paquets FIPS corrigés après la découverte, par un client, d’un problème affectant les images de conteneurs Ubuntu Pro 22.04 FIPS. Celles-ci pouvaient échouer sur les noyaux Linux mainline standards employés dans des environnements Kubernetes managés, notamment AWS EKS et Fargate. L’incident survenait même lorsque l’hôte et le conteneur étaient par ailleurs configurés pour exécuter des charges de travail FIPS.

Une dépendance propre au noyau

Selon Canonical, libgcrypt20-fips dépendait de GRND_RESEED_ONLY, un indicateur de noyau propre à Ubuntu et intégré à son implémentation FIPS. Cet indicateur n’existe pas dans les noyaux mainline standards. Lorsque le paquet appelait getrandom() avec cette option non prise en charge, l’appel système renvoyait une erreur et provoquait l’échec du conteneur.

Le problème venait donc d’une hypothèse concernant le noyau sous-jacent, et non d’une mauvaise configuration du conteneur. Même un hôte conforme aux exigences FIPS et une image correctement construite pouvaient être touchés lors d’un déploiement sur une plateforme Kubernetes managée utilisant une autre famille de noyaux.

La contrainte de conformité

Canonical explique que le correctif devait assurer la compatibilité avec les noyaux standards tout en préservant le statut FIPS des composants concernés. Toute modification de paquets cryptographiques peut imposer une nouvelle validation dans le cadre du Cryptographic Module Validation Program du National Institute of Standards and Technology, ce qui risquerait de créer un obstacle réglementaire distinct pour les déploiements soumis à des exigences de conformité.

Le correctif modifie le comportement de libgcrypt20-fips, gnutls28 et ubuntu-fips lorsque GRND_RESEED_ONLY n’est pas disponible. Ces paquets peuvent désormais recourir à un mécanisme de repli sans compromettre les garanties cryptographiques décrites par Canonical.

Des paquets désormais disponibles

Canonical a d’abord fourni les paquets corrigés au client par l’intermédiaire d’un PPA privé afin qu’il puisse les valider. D’après l’entreprise, le client a testé les conteneurs dans ses environnements cibles et confirmé le bon fonctionnement du correctif.

Canonical a ensuite publié les mises à jour dans les dépôts jammy-fips-updates et noble-fips-updates. Le scénario concerné comprend les images de conteneurs Ubuntu Pro 22.04 et 24.04 FIPS exécutées sur des noyaux cloud standards. Cet incident montre que la compatibilité d’un déploiement FIPS dépend de l’interaction entre les paquets certifiés et le noyau de l’hôte, et pas uniquement de la certification de l’image.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

Source: How a missing kernel flag broke FIPS-certified containers in managed Kubernetes