Amazon lance Bottlerocket 1.0.0, une distribution Linux basée sur des conteneurs isolés

Amazone présenté première version majeure d'une distribution Linux dédiée Fusée à bouteille 1.0.0, conçu pour faire fonctionner efficacement et en toute sécurité des conteneurs isolés. La boîte à outils et les composants de contrôle de la distribution sont écrits en Rust et propagé sous licence MIT et Apache 2.0. Le projet est en cours de développement sur GitHub et est disponible pour la participation des représentants de la communauté. L'image de déploiement du système est générée pour les architectures x86_64 et Aarch64. Le système d'exploitation est adapté pour fonctionner sur les clusters Amazon ECS et AWS EKS Kubernetes. Sont prévus outils et pour créer vos propres builds et éditions qui peuvent utiliser d'autres outils d'orchestration, noyaux et runtime pour conteneurs.

La distribution fournit un noyau Linux et un environnement système minimal qui inclut uniquement les composants nécessaires à l'exécution des conteneurs. Parmi les packages impliqués dans le projet, le gestionnaire de système systemd, la bibliothèque Glibc et la boîte à outils d'assemblage sont notés
Buildroot, chargeur de démarrage GRUB, configurateur réseau méchant, runtime pour les conteneurs isolés conteneur, l'infrastructure d'orchestration de conteneurs Kubernetes, l'aws-iam-authenticator et l'agent Amazon ECS.

La distribution est mise à niveau de manière atomique et est livrée sous la forme d'une image système indivisible. Deux partitions de disque sont allouées au système, dont l'une contient le système actif, et la mise à jour est copiée sur la seconde. Une fois la mise à jour déployée, la deuxième partition devient active et dans la première, jusqu'à l'arrivée de la prochaine mise à jour, la version précédente du système est enregistrée, sur laquelle, en cas de problème, vous pouvez revenir en arrière. Les mises à jour sont installées automatiquement sans intervention de l'administrateur.

Une différence clé par rapport aux distributions similaires telles que Fedora CoreOS, CentOS/Red Hat Atomic Host est l'objectif principal de fournir sécurité maximale dans le cadre du renforcement de la protection du système contre d'éventuelles menaces, compliquant l'exploitation des vulnérabilités des composants de l'OS et augmentant l'isolement des conteneurs. Les conteneurs sont créés en utilisant les mécanismes habituels du noyau Linux - cgroups, namespaces et seccomp. Pour une isolation supplémentaire, la distribution utilise SELinux en mode "enforcing", et le module est utilisé pour la vérification cryptographique de l'intégrité de la partition racine. dm-Verity. Si une tentative de modification des données au niveau du périphérique bloc est détectée, le système redémarre.

La partition racine est montée en mode lecture seule et la partition avec les paramètres /etc est montée dans tmpfs et restaurée à son état d'origine après un redémarrage. La modification directe des fichiers dans le répertoire /etc, tels que /etc/resolv.conf et /etc/containerd/config.toml, n'est pas prise en charge - pour enregistrer définitivement les paramètres, vous devez utiliser l'API ou déplacer la fonctionnalité vers des conteneurs séparés.

La plupart des composants système sont écrits en Rust, qui fournit des outils sécurisés en mémoire pour éviter les vulnérabilités causées par l'adressage d'une zone mémoire après sa libération, le déréférencement des pointeurs nuls et les dépassements de mémoire tampon. Lors de la construction par défaut, les modes de compilation "--enable-default-pie" et "--enable-default-ssp" sont utilisés pour activer la randomisation de l'espace d'adressage des fichiers exécutables (TARTE) et la protection contre le débordement de la pile via la substitution d'étiquette Canary.
Pour les packages écrits en C/C++, des indicateurs supplémentaires sont inclus
"-Wall", "-Werror=format-security", "-Wp, -D_FORTIFY_SOURCE=2", "-Wp, -D_GLIBCXX_ASSERTIONS" et "-fstack-clash-protection".

Les outils d'orchestration de conteneurs sont fournis dans un conteneur de contrôle, qui est activé par défaut et contrôlé via API et l'agent AWS SSM. L'image de base manque d'un shell de commande, d'un serveur SSH et de langages interprétés (par exemple, pas de Python ou de Perl) - les outils d'administration et de débogage sont déplacés vers conteneur de service séparé, qui est désactivé par défaut.

Source: opennet.ru

Ajouter un commentaire