Amazon Linux 2027 passe SELinux en mode enforcing par défaut
La préversion publique d’Amazon Linux 2027 est disponible depuis le 3 septembre, avec un noyau 7.1, SELinux en mode enforcing par défaut et les pilotes AWS Neuron. Testez-la dès maintenant si vous planifiez une migration depuis AL2023.
3 septembre 2026. AWS annonce la préversion publique d’Amazon Linux 2027 (AL2027), la prochaine version majeure de son système d’exploitation pensé pour les charges cloud. 7 septembre 2026. La distribution occupe la tête de la Weekly Roundup d’AWS, qui confirme son arrivée dans toutes les régions commerciales. Pourquoi c’est important : AL2027 définira la base de vos EC2 pour les deux prochaines années, et deux choix de fond — SELinux en mode enforcing par défaut et un noyau 7.1+ — changeront le comportement des applications que vous y déployez.
Ce qui change par rapport à AL2023
AL2027 s’appuie sur la base d’AL2023 plutôt que de repartir de zéro, ce qui réduit l’effort de migration. La liste des changements annoncés tient en cinq points :
- Noyau Linux 7.1+ : la distribution saute directement sur la série 7.x, celle que ce blog suit depuis la sortie de la 7.2 cet été.
- SELinux en mode enforcing par défaut : le contrôle d’accès obligatoire est actif dès le premier démarrage, pas seulement disponible.
- AWS-LC pour la cryptographie : la bibliothèque de Amazon remplace OpenSSL sur le chemin critique pour accélérer le chiffrement.
- Toolchains et runtimes à jour : compilateurs, langages et runtimes récents pour les builders.
- Pilotes d’accélérateurs, dont AWS Neuron : le support des puces Trainium et Inferentia est intégré nativement.
Le choix du noyau 7.1+ n’est pas anodin : il aligne AL2027 sur la série Linux 7.x que suit ce blog, avec ses travaux sur la sûreté mémoire et le Rust. La distribution hérite ainsi des améliorations récentes du noyau sans attendre une mise à jour majeure ultérieure.
AL2027 poursuit la cadence biennale de la famille — AL2023 en 2023, AL2025 en 2025, AL2027 en 2027 — tout en conservant la promesse d’une base minimale, sans serveur graphique ni outillage superfétatoire.
Cette régularité est un argument d’exploitation à part entière : elle donne aux équipes une feuille de route prévisible. Chaque version majeure reçoit un support pluriannuel, si bien qu’un parc peut rester sur AL2023 ou AL2025 sans urgence, tout en sachant exactement quand la génération suivante arrive et ce qu’elle change. AL2025, la version stable actuelle, demeure le choix sûr pour la production ; AL2027 est la cible à valider en prévision de la bascule.
SELinux enforcing : le vrai changement de fond
Le point le plus lourd de conséquences n’est pas le noyau, mais le passage de SELinux à l’état enforcing par défaut. Historiquement, Amazon Linux livrait SELinux présent mais permissif : les violations étaient journalisées, jamais bloquées. AL2027 inverse ce défaut.
Concrètement, une application qui écrit au mauvais endroit — un agent qui touche à /etc ou un service qui écoute sur un port non déclaré — sera désormais bloquée, et pas seulement signalée dans audit.log. C’est la bonne décision de sécurité, mais c’est aussi la source la plus probable de régressions lors d’une migration depuis AL2023.
Le diagnostic est standard :
sudo grep -i denied /var/log/audit/audit.log | tail -20
sudo audit2why -aLe réflexe à proscrire est le setenforce 0 définitif : il transforme un contrôle de sécurité en variable morte. Si une charge ne tolère pas enforcing, mieux vaut une politique ciblée via audit2allow qu’une désactivation globale.
Ce qui casse concrètement en migration
Le passage à enforcing révèle trois familles de problèmes récurrentes quand on déplace une charge depuis AL2023. D’abord les ports non déclarés : un service qui écoute sur un port hors de sa politique — par exemple un reverse proxy sur 8080 au lieu de 80 — se fait couper l’accès tant que le port n’est pas labellisé avec semanage port. Ensuite les chemins non standards : une application qui écrit dans /srv ou /opt plutôt que dans /var/lib voit ses écritures refusées jusqu’à l’ajout d’une règle semanage fcontext. Enfin les services maison qui tournent en root sans politique dédiée : ils héritent du domaine unconfined_service_t et se comportent comme avant, ce qui masque leur véritable surface.
Le réflexe productif consiste à traiter enforcing comme un outil de découverte. Les dénis AVC (Access Vector Cache) consignés dans audit.log documentent ce que vos applications font réellement ; chaque déni corrigé par politique affine votre modèle de moindre privilège. C’est précisément l’effet recherché par AWS : faire de la politique SELinux un actif, pas un fardeau.
AWS-LC et la cryptographie accélérée
AWS-LC est la bibliothèque cryptographique general-purpose de Amazon, dérivée de BoringSSL, validée FIPS 140-3. En la plaçant sur le chemin par défaut, AL2027 promet un TLS et un chiffrement de disque plus rapides sur les instances récentes, notamment celles qui exploitent les instructions AES-NI et les extensions vectorielles des processeurs Graviton.
Pour un opérateur, le gain se mesure surtout sur les charges TLS-heavy — reverse proxies, API exposées, transferts S3 — où la latence de chiffrement est le premier poste de coût CPU. Le basculement est transparent tant que votre application ne dépend pas d’une version précise d’OpenSSL avec des patches maison.
Neuron et les charges IA/ML
Le troisième pilier d’AL2027 est l’intégration native du support des accélérateurs AWS : les pilotes Neuron couvrent les puces Trainium et Inferentia, sans installation manuelle. C’est un signal clair de la direction d’AWS : le système d’exploitation devient la couche d’accueil par défaut des charges d’inférence et d’entraînement maison, au même titre que les EC2 à base de GPU NVIDIA.
Pour les équipes qui exécutent des modèles via Neuron ou EC2 Trn1/Inf2, AL2027 élimine l’étape de bootstrap du SDK. Pour les autres, le changement est neutre.
Comment tester la préversion
La préversion est distribuée sous deux formes :
- AMI disponibles dans la console AWS, sur toutes les régions commerciales, en variantes x86-64 et ARM.
- Images de conteneurs de base sur le Amazon ECR Public Gallery.
Le retour se fait par le dépôt GitHub d’AL2027, et la documentation détaille la liste complète des changements par rapport à AL2023. La préversion précède la disponibilité générale : c’est le moment de valider vos images, vos user data et vos politiques de sécurité avant la bascule en production.
La checklist de validation tient en quatre points : construire vos AMI à partir des images de base, rejouer vos user data de bootstrap pour vérifier qu’elles s’exécutent sous SELinux enforcing, dérouler vos tests d’intégration sur la variante ARM si vous tournez sur Graviton, et mesurer l’impact d’AWS-LC sur vos charges TLS. Chaque point qui passe aujourd’hui est un point de moins à régler le jour de la GA.
Verdict
Si vous exécutez des charges IA/ML sur Trainium ou Inferentia, testez AL2027 dès maintenant : le support Neuron natif vous épargne le bootstrap du SDK et la préversion suffit à valider vos pipelines d’inférence.
Si vous opérez un parc EC2 sur AL2023, prévoyez un bac à sable dédié pour vérifier la compatibilité SELinux enforcing : c’est le point qui cassera vos applications avant tout le reste, et il se règle par politique ciblée, pas par désactivation.
Si vous restez sur AL2023 ou AL2025, rien ne presse : les deux versions restent supportées, mais le passage à enforcing par défaut est la trajectoire à anticiper dès maintenant dans vos recettes de déploiement.