Images FIPS indépendantes du noyau

Les images FIPS de Chainguard sont désormais disponibles pour un déploiement sur n'importe quel noyau Linux. Auparavant, les développeurs devaient fournir du matériel dédié et des machines virtuelles (VM) avec le noyau hôte configuré en mode FIPS. Dans les environnements cloud natifs ou partagés, cette exigence augmentait considérablement la complexité opérationnelle en obligeant à dépendre d'un ensemble limité de noyaux compatibles FIPS. Pour les équipes d'ingénierie et de sécurité, cela signifiait des correctifs et la maintenance de logiciels hérités coûteux. Pour les équipes chargées de la conformité, cela signifiait des obstacles supplémentaires sur le chemin de l'obtention et du maintien de la conformité avec les réglementations critiques.

Chainguard FIPS Images élimine ces frictions grâce à une nouvelle conception qui remplace la source d'entropie du noyau par celle de l'espace utilisateur. Cette implémentation permet aux développeurs de déployer des charges de travail FIPS en utilisant les derniers noyaux, matériels et types d'instances. Les images FIPS de Chainguard débloquent ainsi la possibilité d'exécuter des charges de travail FIPS sur des machines de développeur, des déploiements CI/CD existants, et même sur des offres de cloud gérées non FIPS facilement disponibles. Tout cela peut être fait en utilisant les derniers systèmes d'exécution de l'espace utilisateur comme NodeJS, Python, Go, PHP, .NET, et C/C++, entre autres.

Avec Chainguard, vous pouvez créer des logiciels de meilleure qualité et plus sûrs en déployant des charges de travail sur le matériel le plus récent, les types d'instances les plus performants et les derniers temps d'exécution des applications. Les images Chainguard offrent toute cette flexibilité tout en maintenant zéro CVE dans le cadre de notre SLA, en assurant la conformité FIPS et en éliminant les investissements redondants dans des systèmes d'exploitation spécifiques FIPS.

Dans cet article, nous examinerons de plus près la "conception d'hier" des déploiements FIPS et ce que Chainguard fait pour faciliter le déploiement FIPS aujourd'hui.

FIPS générique Hier

La protection cryptographique repose sur la mise en œuvre sécurisée d'un algorithme de confiance et d'un générateur de bits aléatoires qui ne peut être raisonnablement prédit avec plus de précision que le hasard. Pour certifier ces implémentations, le National Institute of Standards and Technology (NIST) gère un programme de certification cryptographique appelé Cryptographic Module Validation Program (CMVP). Le CMVP valide la conformité de l'implémentation avec les normes pertinentes ci-dessous.

• Pour l'implémentation d'algorithmes, le CMVP exige une conformité stricte avec les normes FIPS. Les modules FIPS doivent donc se situer à l'intérieur d'une frontière cryptographique auto-vérifiée.

• Pour les générateurs de bits aléatoires, le CMVP exige une stricte conformité avec les recommandations du SP 800-90B et permet aux sources d'entropie de se situer à l'intérieur ou à l'extérieur de la frontière cryptographique FIPS.

Traditionnellement, pour satisfaire à cette exigence de conformité, les conteneurs accèdent à une source d'entropie conforme à la norme SP 800-90B fournie par un noyau certifié. Voir la figure 1 pour une représentation graphique de cette combinaison.

Cette conception pose un problème majeur : si les applications conteneurisées ont besoin d'accéder à la source d'entropie du noyau, elles n'utilisent pas le module FIPS du noyau. La conception ci-dessus crée inutilement une dépendance à l'égard d'une deuxième frontière cryptographique FIPS, ce qui entraîne une duplication des efforts de maintenance et de certification.

Cette conception, qui nécessite la maintenance des limites cryptographiques FIPS au niveau du noyau, entraîne des frictions importantes pour les fournisseurs qui proposent des charges de travail conformes aux normes FIPS pour les applications cloud-natives modernes. Tout d'abord, très peu de versions du noyau Linux sont certifiées. Deuxièmement, les délais de certification du noyau Linux sont souvent longs et ardus.

En fin de compte, cela se traduit par un choix très limité de moteurs d'exécution certifiés et de matériel sous-jacent compatible sur lesquels les développeurs peuvent s'appuyer. En pratique, cela signifie qu'un noyau certifié d'un fournisseur donné peut avoir plus de 5 ans. Les noyaux obsolètes ne prennent généralement pas en charge et n'optimisent pas la dernière génération de matériel, et sont souvent incompatibles avec les derniers types d'instances en nuage. Cela signifie également que si l'on s'en tient au même fournisseur, les moteurs d'exécution des applications sont tout aussi obsolètes et vulnérables.

Chainguard FIPS aujourd'hui

Chainguard a introduit et mis en œuvre une solution plus propre dans laquelle le module FIPS et la source d'entropie SP 800-90B peuvent être installés dans l'espace utilisateur de l'image du conteneur. Il n'est donc plus nécessaire de disposer d'un noyau Linux certifié pour la majorité des charges de travail et l'effort d'ingénierie pour les déploiements de charges de travail s'en trouve rationalisé. C'est pourquoi les images FIPS de Chainguard sont désormais livrées avec une source d'entropie certifiée SP 800-90B en espace utilisateur. Voir la figure 2 pour une représentation graphique de ce nouveau FIPS indépendant du noyau.

Grâce à la nouvelle conception de Chainguard, l'image de conteneur pour une application FIPS donnée peut être entièrement autonome, minimale et sans distribution. Chaque image de conteneur est livrée avec un module FIPS certifié et une source d'entropie SP 800-90B certifiée. Cette image de conteneur peut être déployée sur n'importe quel environnement d'exploitation confirmé par l'utilisateur, y compris les dernières générations de matériel et les versions du noyau hôte.

En outre, la conception de Chainguard est disponible pour la majorité des écosystèmes de langages de programmation tels que Python, NodeJS, Go, .NET, PHP, C/C++ et d'autres. La bibliothèque standard de chaque écosystème respectif utilise OpenSSL, qui a lui-même été configuré au moment de l'exécution pour utiliser un module FIPS certifié et une source d'entropie SP 800-90B certifiée. En bref, cette conception permet une cryptographie conforme aux normes FIPS lors de l'utilisation de la plupart des écosystèmes de langages de programmation. Voir les certifications de Chainguard ici.

La majorité de nos images FIPS sont maintenant des images FIPS indépendantes du noyau, y compris :

• python-fips : 3.10, 3.11, 3.12, 3.13

• nodejs-fips : 18, 20, 21, 22, 23

• go-fips & go-msft-fips : 1.21, 1.22, 1.23

• dotnet-fips : 6, 7, 8, et bientôt 9

• php-fips : 8.2, 8.3, et bientôt 8.4

... et beaucoup d'autres applications construites au-dessus de ces écosystèmes linguistiques. Consultez notre catalogue complet de plus de 300 images Chainguard FIPS pour voir ce que nous offrons.

Les développeurs peuvent exécuter tous ces conteneurs dans une grande variété de déploiements et de cas d'utilisation :

• Postes de travail des développeurs

• Pipelines CI/CD existants

• Déploiements nécessitant une certification FIPS comme FedRAMP et DoD

Avec une base de code, des dépendances et un déploiement unifiés, vous pouvez atteindre la norme FIPS par défaut, sans effort supplémentaire ardu.

Limitations

Certaines charges de travail nécessitent une source d'entropie SP 800-90B du noyau ou un module FIPS du noyau. Il s'agit notamment, mais pas exclusivement, des éléments suivants Les images FIPS Chainguard expédiant Java (EDIT 20 AOUT 2025 : Ce n'est plus le cas, car nous avons annoncé des images FIPS indépendantes du noyau pour Java), les plugins CNI k8s, le chiffrement de disque complet LUKS2, et StrongSwan VPN. Ces cas d'utilisation continueront à nécessiter un noyau en mode FIPS.

Une solution entièrement open-source

Pour mettre en œuvre notre conception FIPS indépendante du noyau, Chainguard s'est appuyé sur ses partenariats commerciaux et ses liens étroits avec la communauté open-source. Nous nous sommes appuyés sur des logiciels entièrement libres et avons reversé notre mise en œuvre à la communauté. Le travail d'ingénierie permettant à OpenSSL d'utiliser la bibliothèque Jitter Entropy a été apporté par Chainguard au projet OpenSSL dans la version 3.4.0, sous une licence permissive Apache-2.0. La technologie de la bibliothèque Jitter Entropy est utilisée par la majorité des noyaux Linux FIPS pour obtenir la certification en tant que source d'entropie SP 800-90B.

Grâce au contrat de support d'OpenSSL, nous avons pu obtenir la certification du module FIPS d'OpenSSL avec le laboratoire de certification Acumen. En collaboration avec le laboratoire de certification de l'Atsec, nous avons pu certifier la source d'entropie SP 800-90B en un temps record.

En fin de compte, Chainguard a créé une implémentation d'image de conteneur FIPS de niveau de production qui est entièrement open-source.

Images FIPS de Chainguard : Aucun compromis nécessaire

Chainguard FIPS Images est une solution idéale pour les déploiements de produits SaaS, on-prem et de périphériques physiques. Chainguard permet aux développeurs d'unifier leurs bases de code et leurs dépendances d'exécution entre les lignes de produits commerciales et FIPS, et de standardiser leur choix de noyau Linux. Les organisations d'ingénierie ne sont plus obligées de faire des compromis entre le choix du logiciel le plus récent et le plus performant, le matériel compatible et la conformité FIPS.

Dans le cadre de notre mission visant à devenir la source sûre de l'open source, nous faciliterons la création de meilleurs logiciels. Cela signifie mettre à jour les noyaux plus rapidement, rester proche de la version de distribution principale et sécuriser le noyau par défaut.

Consultez notre catalogue complet de plus de 300 images Chainguard FIPS, et contactez-nous si vous souhaitez en savoir plus !