Pourquoi Kubernetes a supprimé PodSecurityPolicy et ce qui l'a remplacé

Dans un article publié sur le blog Kubernetes en août 2022, le projet a fourni le contexte historique de la suppression de PodSecurityPolicy (PSP). Ce contrôleur d'admission a été officiellement supprimé dans Kubernetes v1.25 après un long cycle de dépréciation commencé avec la version v1.21. L'article explique pourquoi PSP n'a jamais atteint le statut stable et comment son successeur, Pod Security Admission, corrige ces lacunes.

Que s'est-il passé ?

PodSecurityPolicy est issu des SecurityContextConstraints (SCC) d'OpenShift, qui existaient dès la première version de Red Hat OpenShift Container Platform avant Kubernetes 1.0. PSP était essentiellement une version allégée des SCC conçue pour Kubernetes upstream. Sa création précédait le processus formel de proposition d'amélioration Kubernetes (KEP), rendant l'historique de sa conception initiale difficile à retracer. Cependant, les archives montrent que la proposition de conception finale a été créée après que les premières fusions de code avaient déjà commencé.

Les racines de PSP ont été ajoutées via une série de pull requests à partir de 2015. Avant l'existence de PSP, Kubernetes 1.0, sorti le 10 juillet 2015, ne disposait pas de mécanismes permettant de restreindre les contextes de sécurité au-delà d'un plugin de qualité alpha appelé SecurityContextDeny. Le premier objet PSP, basé sur les SCC d'OpenShift, a été fusionné dans Kubernetes upstream en février 2016 après neuf mois de discussion. Le contrôleur d'admission a suivi en mai 2016, avec des mécanismes d'autorisation ajoutés plus tard cette même année pour permettre différentes politiques pour différents utilisateurs.

Malgré ses intentions, PSP n'a jamais obtenu le statut stable. Il souffrait d'un modèle d'autorisation défaillant, de difficultés de déploiement et d'une API incohérente. En conséquence, la communauté Kubernetes a décidé de le supprimer entièrement dans la v1.25. Il a été remplacé par Pod Security Admission, un nouveau plugin intégré qui applique les normes de sécurité des pods (Pod Security Standards) au niveau du namespace.

Comment cela fonctionne-t-il ?

PodSecurityPolicy fonctionnait comme un plugin de contrôle d'admission spécialisé offrant des permissions granulaires sur les champs de sécurité des pods. Son objectif était de découpler les décisions de sécurité Linux de bas niveau du processus de déploiement, permettant aux administrateurs de cluster de définir des valeurs par défaut sécurisées sans exiger que chaque utilisateur comprenne des primitives de sécurité complexes. Le système reposait sur la mutation et la validation pour appliquer des règles telles que l'exécution en tant qu'utilisateur non-root ou la restriction de l'escalade de privilèges.

Cependant, PSP fonctionnait selon un principe « fail-closed » (échec sécurisé). Si aucune politique n'existait, tous les pods étaient refusés. Cela rendait son activation par défaut difficile, car les administrateurs devaient créer des politiques pour chaque charge de travail avant d'activer la fonctionnalité. Il n'y avait pas de mode audit pour identifier quels pods échoueraient sous les nouvelles politiques, entraînant des ruptures fréquentes et une couverture de test insuffisante. De plus, l'API est devenue incohérente au fil du temps en accommodant des cas d'utilisation de niche, ce qui rendait sa composition avec d'autres contrôleurs d'admission difficile.

Le remplacement, Pod Security Admission, simplifie ce modèle en appliquant trois normes prédéfinies de sécurité des pods : Privileged, Baseline et Restricted. Privileged est sans restriction, Baseline autorise les configurations par défaut et Restricted impose les bonnes pratiques de sécurité. Cette approche élimine le besoin d'une connaissance approfondie de la sécurité pour la plupart des utilisateurs et fournit un mécanisme d'application stable au niveau du namespace, plus facile à adopter et à maintenir.

Détails clés

• PodSecurityPolicy a été supprimé dans Kubernetes v1.25 après avoir été déprécié dans la v1.21.
• PSP est issu des SecurityContextConstraints d'OpenShift et a été fusionné dans Kubernetes en février 2016.
• La fonctionnalité n'a pas atteint le statut stable en raison d'un modèle d'autorisation défaillant et d'une complexité de déploiement.
• PSP fonctionnait selon un principe « fail-closed », exigeant des politiques pour toutes les charges de travail avant l'activation.
• Pod Security Admission remplace PSP avec trois normes : Privileged, Baseline et Restricted.
• Le nouveau contrôleur d'admission est stable dans Kubernetes v1.25 et opère au niveau du namespace.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de plateforme, comprendre le passage de PSP à Pod Security Admission est crucial pour maintenir des clusters sécurisés. PSP nécessitait une expertise significative dans les primitives de sécurité Linux et une gestion minutieuse des politiques pour éviter de casser les déploiements. Sa suppression signale une évolution vers des valeurs par défaut de sécurité plus simples et plus opinionnées, plus faciles à mettre en œuvre et moins sujettes aux erreurs de configuration.

Les nouvelles normes de sécurité des pods offrent une voie claire pour sécuriser les charges de travail sans la surcharge liée à la gestion de politiques personnalisées complexes. En se concentrant sur trois niveaux distincts de restriction, Kubernetes facilite l'adoption des bonnes pratiques de sécurité par les développeurs sans nécessiter une connaissance approfondie des mécanismes de sécurité sous-jacents. Ce changement réduit le risque de mauvaise configuration et améliore la posture de sécurité globale des clusters Kubernetes.

Ce que vous pouvez faire

• Mettez à jour vos clusters vers Kubernetes v1.25 ou ultérieur pour utiliser le contrôleur stable Pod Security Admission.
• Examinez vos charges de travail existantes pour vous assurer qu'elles sont conformes aux normes de sécurité des pods Baseline ou Restricted.
• Remplacez tout objet PodSecurityPolicy restant par des étiquettes au niveau du namespace qui imposent la norme de sécurité souhaitée.
• Utilisez le mode audit disponible dans les versions antérieures pour identifier les pods qui échoueraient sous les nouvelles normes avant de les imposer.
• Consultez la documentation Kubernetes pour des tutoriels pratiques sur la mise en œuvre de Pod Security Admission.
• Pour les cas d'utilisation sophistiqués non couverts par les normes intégrées, évaluez les contrôleurs d'admission tiers pouvant compléter Pod Security Admission.