Amazon MSK ajoute TLS 1.3, avec une migration à tester

Ce qui change

Amazon MSK permet désormais de sélectionner TLS 1.3 pour chiffrer les données en transit. Une politique détermine les versions du protocole et les méthodes de chiffrement acceptées. Le choix porte sur les liaisons chiffrées gérées par MSK, au-delà des seules connexions des applications. Annonce AWS du 30 octobre 2026.

Deux possibilités s’ajoutent au fonctionnement par défaut en TLS 1.2 : accepter simultanément TLS 1.2 et TLS 1.3, ou n’autoriser que TLS 1.3. La première permet de conserver les clients limités à TLS 1.2. Elle ne garantit toutefois pas la compatibilité de tous les logiciels : un client qui annonce TLS 1.3 mais échoue lors de l’établissement de la connexion ne se rabat pas sur TLS 1.2.

Les environnements concernés

L’option vise MSK Provisioned avec Apache Kafka 3.6 ou une version ultérieure. MSK Serverless est exclu. Avant une modification, le cluster doit être dans l’état ACTIVE, sans autre opération en cours, et l’intervenant doit disposer des droits de modification de la configuration et du cluster.

Les bibliothèques des applications et les équipements intermédiaires doivent être vérifiés. Pour TLS 1.3, MSK accepte les suites AES-GCM à 128 ou 256 bits ; un client proposant uniquement ChaCha20-Poly1305 ne peut pas établir cette connexion. Ces limites sont détaillées dans le guide des politiques TLS.

Une activation volontaire, par étapes

AWS annonce cette capacité sans supplément tarifaire dans toutes les régions proposant MSK Provisioned. Les clusters existants ne changent pas tant qu’aucune politique n’est appliquée. Aucun délai obligatoire de migration n’est fixé dans l’annonce.

Pour un cluster existant, passer du réglage par défaut à TLS 1.3 exclusivement exige deux mises à jour : appliquer d’abord la politique mixte, attendre son achèvement, puis appliquer la politique exclusive. Un nouveau cluster peut sélectionner directement cette dernière si ses clients sont compatibles. Le retour arrière suit également les paliers adjacents.

Préparer votre décision et l’essai

• Confirmez le type de service, la version de Kafka, les droits nécessaires et la politique actuellement appliquée.
• Testez d’abord la politique mixte hors production, comme le recommande AWS, avec les applications, outils et intermédiaires réellement utilisés.
• Préservez les autres paramètres : la nouvelle révision remplace la configuration existante. Utilisez la propriété tls.security.policy documentée, sans modifier directement les paramètres TLS de chaque serveur Kafka.
• Préparez le redémarrage progressif. AWS conditionne la poursuite du trafic à au moins trois répliques par sujet, à un minimum de répliques synchronisées ne dépassant pas le nombre de répliques moins un, et aux nouvelles tentatives des clients.
• Documentez le retour au palier précédent. Un retour au réglage par défaut exclut les clients configurés exclusivement pour TLS 1.3 : vérifiez aussi cette compatibilité avant de revenir en arrière.

Pour organiser cet environnement et son exploitation, VCSTS peut prendre en charge la conception, la mise en place, la migration et l’exploitation selon le mandat retenu.