Bottlerocket – un OS Linux minimal et immuable avec démarrage vérifié
(bottlerocket.dev)- Bottlerocket est un OS basé sur Linux conçu pour l’hébergement de conteneurs, utilisé comme système d’exploitation de base pour les nœuds workers de clusters gérés par des orchestrateurs comme Kubernetes
- Sa configuration minimale, débarrassée des paquets, outils et interpréteurs des distributions généralistes, réduit la charge d’exploitation et la surface d’attaque, tandis que des variants propres à chaque environnement ne fournissent que les combinaisons nécessaires
- Il ne fournit ni shell ni gestionnaire de paquets ; le système se pilote via un conteneur host privilégié et une API, et les mises à jour sont appliquées de façon atomique par bascule d’images et de partitions
- La configuration est gérée via API, ce qui permet les migrations entre versions et les rollbacks ; la gestion des mises à jour peut être manuelle ou assurée par des outils propres à l’orchestrateur
- Un système de fichiers racine immuable, dm-verity, un SELinux restrictif, ainsi qu’une implémentation en Rust et en partie en Golang réduisent les possibilités d’altération du système et les chemins d’exécution de code non vérifié
OS de base pour clusters de conteneurs
- Bottlerocket est un système d’exploitation basé sur Linux optimisé pour l’hébergement de conteneurs
- C’est un logiciel open source gratuit, développé publiquement sur GitHub
- Il s’installe comme système d’exploitation de base sur les machines ou instances qui exécutent les conteneurs
- Il est conçu pour fonctionner avec des orchestrateurs de conteneurs comme Kubernetes, afin de prendre en charge l’automatisation du cycle de vie des conteneurs au sein d’un cluster
- Il peut s’exécuter dans le cloud comme en datacenter
- Ses objectifs de conception se résument en trois points : Minimal, Safe Updates et Security Focused
Configuration minimale et variants par environnement
- Comme il vise uniquement l’hébergement de conteneurs, de nombreux paquets, outils, interpréteurs et dépendances inclus par défaut dans les distributions Linux généralistes ont été retirés
- La réduction des logiciels inutiles diminue à la fois la charge opérationnelle et le surcoût de sécurité
- Les besoins liés aux différents orchestrateurs, plateformes et architectures sont gérés via des variants, des builds correspondant à chaque combinaison compatible
- Un variant assemble les éléments nécessaires à l’exécution dans un environnement donné
- En choisissant le variant approprié, aucun élément supplémentaire n’est nécessaire pour rejoindre le cluster
- Bottlerocket lui-même ne dispose pas de shell
- L’accès au système est possible via un conteneur host privilégié disposant d’un shell
- Depuis le conteneur host, il est possible d’explorer l’OS sous-jacent et de modifier, via l’API, la configuration du système en cours d’exécution
Mises à jour sûres basées sur des images
- Bottlerocket est conçu pour être mis à jour, mais n’inclut pas de gestionnaire de paquets
- Les mises à jour sont distribuées sous forme d’images téléchargées vers une partition spécifique
- Lors d’une mise à jour, l’orchestrateur draine le nœud, puis demande à Bottlerocket d’appliquer la mise à jour et de redémarrer
- Bottlerocket échange les partitions et démarre de façon atomique sur la nouvelle version
- La configuration du système est gérée via API, ce qui permet à Bottlerocket de prendre en charge la migration des paramètres entre versions
- En cas de problème pendant la mise à jour, il est possible de revenir à la version précédemment fonctionnelle tout en conservant la configuration
- La gestion des mises à jour peut être effectuée manuellement ou via des outils propres à l’orchestrateur
Conception centrée sur la sécurité
- La configuration minimale et le mécanisme de mise à jour soutiennent la conception centrée sur la sécurité de Bottlerocket
- Les variants étant distribués sous forme d’images, il n’est pas nécessaire d’avoir un registre de paquets ni un gestionnaire de paquets susceptibles de modifier le système et de créer des problèmes de sécurité
- Les fonctionnalités propres à Bottlerocket sont écrites en Rust et en partie en Golang
- Ces deux langages sont compilés et offrent des protections intégrées contre les problèmes de sécurité mémoire
- Tout le code étant fourni sous forme d’images précompilées, il n’y a pas besoin de shell ni d’interpréteurs, ce qui réduit les chemins d’exécution de code non vérifié
- Le système de fichiers racine est immuable
- dm-verity fournit une vérification transparente de l’intégrité du système de fichiers racine
- Si une modification du périphérique bloc sous-jacent est détectée, le noyau redémarre
- Les systèmes de fichiers modifiables sont soumis à une politique SELinux restrictive, toujours activée et appliquée
- Cette politique aide à empêcher l’exécution d’opérations dangereuses, même lorsqu’un conteneur s’exécute en root
1 commentaires
Avis sur Hacker News
Cela garde encore fortement le caractère d’un projet AWS/Amazon, et la voie vers un projet indépendant ne semble pas très claire
Par exemple, si l’on a besoin d’un scan de vulnérabilités de l’OS, on peut utiliser un produit Amazon ; sinon, la méthode est assez floue https://bottlerocket.dev/en/faq/#4_2
Si vous comptez faire tourner Bottlerocket uniquement sur AWS, très bien ; mais pour en faire un produit qui, comme le dit le site, “s’exécute dans le cloud ou dans un datacenter”, il faudra régler ce genre de points
Si vous voulez savoir si les correctifs sont appliqués, il suffit de vérifier que vous exécutez la dernière version ; si c’est le cas, tous les correctifs disponibles sont déjà appliqués
Cela dit, dans les secteurs réglementés, cela peut poser problème parce qu’il faut remplir la case “gestion des vulnérabilités” dans les checklists de conformité
La grande raison pour laquelle la gestion des vulnérabilités est nécessaire sur les OS traditionnels, c’est que l’espace de configuration est très vaste, que la composition logicielle mélange arbitrairement plusieurs sources et fournisseurs, et que chaque version évolue indépendamment
Mais un OS pour conteneurs n’est pas fait pour être utilisé ainsi
Trouver des vulnérabilités supplémentaires dans “latest” relève davantage du travail d’un chercheur en sécurité que de celui d’un propriétaire de système appliquant à temps les correctifs upstream
C’est un projet plus ancien que Bottlerocket
S’il existe une façon d’entrer via SSM ou d’utiliser un conteneur admin pour lancer un scan, je me demande simplement si l’on ne pourrait pas faire la même chose
Il suffit de le faire avant de déployer l’image sur la machine hôte
Contrairement à la plupart des distributions *nix d’entreprise, Bottlerocket ne propose pas de mode FIPS
Si vous utilisez un programme de conformité qui exige une cryptographie approuvée FIPS pour l’OS hôte de production, économisez votre temps
Pour cette raison, Bottlerocket n’est pas une option pour nous ; l’issue correspondante est ouverte et active depuis plus de deux ans, mais l’équipe de développement ne semble pas convaincue que ce soit important
Nous en avons aussi parlé avec l’équipe de développement via notre interlocuteur AWS dédié, mais ils ne semblaient pas disposés à l’ajouter
Le fil ouvert depuis plus de deux ans est ici : https://github.com/bottlerocket-os/bottlerocket/issues/1667
La prise en charge de FIPS reste, de loin, la première demande des clients
Cela dit, le moment est mal choisi pour une nouvelle distribution qui n’a pas d’historique de fourniture FIPS
Il n’est plus possible d’obtenir de nouvelles certifications FIPS 140-2, et pour les nouvelles certifications FIPS 140-3, toute l’industrie est en transition, avec de longues files d’attente
Si c’était quelque chose que l’équipe de développement pouvait simplement pousser pour le résoudre, ce serait déjà fait
Je suis désolé si nous avons donné l’impression que ce n’était pas important ; ça l’est réellement, mais dans ce cas cela n’aide pas le calendrier
Si vous en avez besoin, vous n’avez pas le choix, mais personnellement je vois la présence d’une certification comme un signal plutôt négatif
Je ne suis pas le seul à le penser ; l’équipe Microsoft Windows semble avoir un point de vue similaire : https://techcommunity.microsoft.com/t5/microsoft-security-ba...
Même si FIPS en soi n’est pas mauvais, il faut garder à l’esprit qu’il évolue avec de mauvaises personnes et dans de mauvais environnements https://threadreaderapp.com/thread/1433451378391883782.html
Cela a l’air très intéressant, mais comme d’autres commentaires le disent, le chemin pour l’exécuter soi-même paraît flou
La page GitHub n’est indiquée que sur la page principale
J’ai trouvé le guide VMware ici : https://github.com/bottlerocket-os/bottlerocket/blob/develop...
C’est très proche de l’orientation de CoreOS https://fedoraproject.org/coreos/
Ni “Get Started” ni la FAQ n’expliquent comment l’exécuter
C’est un bon projet, mais il existe depuis 2020 : https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...
Je me demande si quelqu’un l’utilise avec succès en dehors d’AWS
Ça semble assez utile pour des usages comme AMD SEV-SNP
Parce que, pour garantir un comportement précis de la machine, il faut des mesures du noyau + initrd + arguments
Idéalement, ce serait bien de l’utiliser comme hyperviseur de conteneurs et de pouvoir générer une attestation liée au hash du conteneur en cours d’exécution
À condition toutefois qu’il n’y ait pas d’échappement de conteneur ; je ne sais pas vraiment où en est l’état de l’art sur ce sujet aujourd’hui
Je préférerais encore utiliser CoreOS
Ont-ils publié quelque chose d’open source largement utilisé en dehors d’AWS ?
Le site web indique qu’il n’y a pas de shell dans l’OS
J’ai du mal à imaginer un conteneur Docker utile qui n’ait pas au moins un script shell
Dans ce cas, l’absence de shell ne signifie-t-elle pas que Bottlerocket est globalement inutilisable, sauf dans quelques scénarios de niche ?
C’est la machine hôte qui n’a pas de shell ; si l’on récupère un conteneur Docker contenant un shell et qu’on l’exécute avec des privilèges, on peut utiliser un shell sur l’hôte
Fournir le binaire du shell de la machine hôte à un conteneur qui tourne sur cet hôte n’est pas une pratique courante
À la place, cette responsabilité est déléguée au conteneur admin, et la connexion effective se fait à celui-ci via SSM/SSH
Si l’on a besoin d’un shell root à ce stade, on peut utiliser l’utilitaire
sheltiePar exemple, il y a distroless
shells | containers | Bottlerocket | OS kernel