Migration à partir des politiques de sécurité des pods : un guide complet (Partie 1 : Transition vers PSA)

Introduction

Alors que Kubernetes continue de se développer en tant que principale plateforme d'orchestration de conteneurs, la sécurité reste une préoccupation majeure pour les organisations déployant des applications conteneurisées. Parmi les outils fondamentaux de l'arsenal de sécurité de Kubernetes, les politiques de sécurité des pods (PSP) ont autrefois joué un rôle central. PSP a permis aux administrateurs de définir et d'appliquer méticuleusement les contraintes de sécurité sur les pods, garantissant que seuls les conteneurs répondant à des normes de sécurité spécifiques pouvaient fonctionner au sein du cluster.

Cependant, le paysage de la sécurité de Kubernetes évolue rapidement et il est important de noter que PSP est désormais obsolète, à partir de Kubernetes 1.25 (voir le lien vers les notes de version urgente de Kubernetes 1.25). Ce changement découle de divers facteurs, notamment la complexité de la gestion et de la maintenance des politiques PSP, qui entraîne souvent des défis opérationnels pour les utilisateurs.

En réponse à cette dépréciation, les organisations recherchent désormais des alternatives modernes à la PSP, qui non seulement répondent aux exigences de sécurité, mais rationalisent également le processus de sécurisation des charges de travail dans Kubernetes .

Dans ce guide complet, nous nous engageons dans un voyage pour gérer ce changement dans les pratiques de sécurité de Kubernetes, en nous concentrant sur la transition vers l'admission à la sécurité des pods (PSA). Le PSA est l’une des alternatives les plus robustes disponibles, et cet article l’explore en profondeur. Cependant, il convient de mentionner que deux autres alternatives, Kyverno et OPA Gatekeeper, seront abordées dans des articles distincts de cette série.

Tout au long de cet article, vous trouverez des instructions détaillées pour configurer et installer PSA, des guides de migration étape par étape pour passer en douceur de PSP à PSA et des commandes précises pour transférer les règles PSP existantes vers PSA. De plus, vous acquerrez les connaissances nécessaires pour évaluer les espaces de noms en vue de la préparation à la migration à l'aide de commandes d'exécution à sec adaptées à PSA.

À la fin de ce guide, vous acquerrez une compréhension globale des forces et des limites de PSA, vous permettant ainsi de prendre une décision éclairée en fonction des exigences de sécurité spécifiques de votre organisation et de l'environnement Kubernetes.

Avec ce guide, vous pouvez moderniser en toute confiance vos pratiques de sécurité Kubernetes, en garantissant que vos charges de travail restent protégées alors que vous dites adieu à l'ère des politiques de sécurité des pods.

Admission de sécurité des pods (PSA)

• PSA applique les normes de sécurité Kubernetes : PSA garantit que les conteneurs respectent les normes de sécurité natives de Kubernetes, qui sont définies par les normes de sécurité des pods. Ces normes classent les politiques de sécurité en trois profils distincts, chacun présentant un niveau de restriction différent :

  
  

  • Privilégié : La politique Privilégié est intentionnellement ouverte et totalement illimitée. En règle générale, cette stratégie cible les charges de travail au niveau du système et de l'infrastructure gérées par des utilisateurs de confiance. Elle se caractérise par une absence de restrictions. Alors que les mécanismes d'autorisation par défaut comme Gatekeeper peuvent intrinsèquement être privilégiés, pour les mécanismes de refus par défaut tels que la politique de sécurité des pods (PSP), la politique privilégiée doit désactiver toutes les restrictions.

  • Baseline : la politique de base est conçue pour être facilement adoptée par les charges de travail conteneurisées courantes tout en empêchant les élévations de privilèges connues. Il s'adresse aux opérateurs d'applications et aux développeurs d'applications non critiques.

  • Restreint : la politique Restreint se concentre sur l'application de bonnes pratiques rigoureuses en matière de renforcement des pods, bien qu'au détriment potentiel d'une certaine compatibilité. Il cible principalement les opérateurs et les développeurs d’applications critiques pour la sécurité, ainsi que les utilisateurs peu fiables. Pour une liste complète des contrôles qui doivent être appliqués ou interdits sous chaque profil, vous pouvez vous référer à la documentation officielle.

    
    

• Pas de transfert direct de règles PSP : contrairement à certaines autres solutions, PSA n'offre pas de méthode simple pour migrer ou modifier directement les règles de la politique de sécurité des pods (PSP). L'objectif principal de PSA est de valider les pods par rapport aux normes de sécurité Kubernetes établies, y compris les profils mentionnés ci-dessus.

• Aucune mutation : bien que PSA soit efficace au niveau de la validation, il ne peut pas modifier ou personnaliser les spécifications du pod comme le pourrait la PSP. L'objectif principal de PSA est d'appliquer les normes de sécurité Kubernetes prédéfinies et n'inclut pas de fonctionnalités permettant de modifier ou de muter les spécifications des pods. Il se concentre principalement sur la validation des pods par rapport à ces normes établies.

Configuration et installation

Étant donné que PSA est un composant natif de Kubernetes, pour le faire fonctionner, il vous suffit de vous assurer que le contrôleur Pod Security Admission (PSA) est activé dans votre cluster Kubernetes. Vous pouvez le faire en exécutant la commande suivante :

kubectl api-versions | grep admission

Étapes de préparation à la migration

Évaluer les autorisations d'espace de noms

Le contrôle de l'admission de la sécurité des pods est influencé par les étiquettes d'espace de noms. Cela implique que les personnes ayant la capacité de mettre à jour, de corriger ou de créer des espaces de noms ont également le pouvoir de modifier les paramètres de sécurité des pods pour ces espaces de noms. Cette modification pourrait potentiellement contourner des politiques de sécurité plus strictes. Avant de continuer, il est essentiel de vérifier que les autorisations d'espace de noms sont attribuées exclusivement aux utilisateurs de confiance et privilégiés. Il est conseillé de s'abstenir d'accorder ces autorisations élevées aux utilisateurs qui n'ont pas besoin d'un tel accès. Si des contraintes supplémentaires sont nécessaires pour configurer les étiquettes de sécurité des pods sur les objets Namespace, envisagez d'utiliser un webhook d'admission pour appliquer ces restrictions.

Rationalisez et normalisez les politiques de sécurité des pods

Avant de migrer vers Pod Security Admission (PSA), il est avantageux de normaliser vos PodSecurityPolicies (PSP) :

• Supprimer les champs non pris en charge : éliminez les options non couvertes par les normes de sécurité des pods. Ces options incluent :

  
  

 .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass

• Éliminer les champs purement mutants : lancez le processus en supprimant les champs qui ont uniquement un effet de mutation et n'ont pas d'impact sur la politique de validation. Ces champs, comme également mentionné dans la référence « Mapping PodSecurityPolicies to Pod Security Standards », incluent :

 .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities

Déterminer le niveau de sécurité du pod approprié

Lorsque vous déterminez le niveau de sécurité des pods approprié pour votre espace de noms, vous pouvez prendre en compte plusieurs méthodes :

Par exigences de sécurité pour l'espace de noms

Si vous connaissez le niveau d'accès attendu et les exigences de sécurité pour l'espace de noms, vous pouvez sélectionner un niveau de sécurité des pods approprié en fonction de ces exigences spécifiques. Cette approche est similaire à la façon dont vous aborderiez les paramètres de sécurité dans un nouveau cluster.

Par les politiques PodSecurityPolicies existantes :

Utilisez la référence « Mappage des politiques de sécurité des pods aux normes de sécurité des pods » pour mapper chacune de vos politiques de sécurité des pods (PSP) existantes à un niveau de norme de sécurité des pods correspondant.
Si vos PSP ne sont pas initialement basées sur les normes de sécurité des pods, vous devrez peut-être prendre une décision. Choisissez un niveau de sécurité des pods au moins aussi permissif que celui de vos PSP, ou optez pour un niveau au moins aussi restrictif. Pour identifier les PSP utilisées pour les pods dans un espace de noms spécifique, utilisez la commande suivante :

 kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u

Par pods existants :

Effectuez un essai à blanc et appliquez la commande label de la section suivante pour tester les niveaux de sécurité de base et restreint des pods. Cela vous aide à évaluer si ces niveaux sont suffisamment permissifs pour vos charges de travail existantes. Choisissez le niveau valide le moins privilégié qui correspond à vos charges de travail existantes.

Test du niveau de sécurité du pod

Une fois que vous avez déterminé le niveau de sécurité des pods pour votre espace de noms (à l'exception du niveau Privilégié), il est important de valider la politique choisie. Pod Security propose des options de test pour garantir un déploiement fluide et le respect des normes de sécurité.

Test de marche à sec :

Utilisez cette méthode pour évaluer l’impact de la politique sélectionnée sans application immédiate.
Pour effectuer une simulation, utilisez la commande suivante, qui mettra en évidence tous les pods existants qui ne répondent pas au niveau de stratégie spécifié :

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

Test du mode audit :

Le mode Audit vous permet d'enregistrer les violations des politiques sans les appliquer. Les pods en violation sont enregistrés dans les enregistrements d'audit pour un examen ultérieur. Activez le mode audit avec la commande :

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL

Si des violations inattendues des règles surviennent pendant les tests, vous pouvez :

• Mettez à jour les charges de travail non conformes pour les aligner sur la politique.
• Ajustez le niveau de sécurité du pod pour l'espace de noms si nécessaire pour répondre aux exigences de votre charge de travail.

Application du niveau de sécurité du pod

Une fois que vous êtes sûr que le niveau de sécurité des pods sélectionné est approprié pour votre espace de noms, vous pouvez procéder à son application. Cette étape garantit que les normes de sécurité souhaitées sont activement appliquées à vos charges de travail au sein de l'espace de noms.

Pour appliquer le niveau de sécurité des pods souhaité sur l'espace de noms, utilisez la commande suivante :

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

L'exécution de cette commande activera et appliquera le niveau de sécurité du pod spécifié, améliorant ainsi la sécurité de votre espace de noms.

Contourner la PSP

Pour contourner efficacement PodSecurityPolicy au niveau de l'espace de noms, vous pouvez lier une stratégie de sécurité des pods (PSP) entièrement privilégiée à tous les comptes de service de l'espace de noms. Ce processus garantit que les pods au sein de l'espace de noms ne sont plus soumis aux modifications ou restrictions imposées par PodSecurityPolicy. Vous pouvez le faire au niveau du cluster ou au niveau d'un espace de noms individuel.

Configuration à l'échelle du cluster (nécessaire une seule fois pour l'ensemble du cluster) :

Créez une politique de sécurité des pods (PSP) entièrement privilégiée en appliquant un fichier de configuration YAML, tel que privilèged-psp.yaml . Cette PSP doit accorder tous les privilèges nécessaires aux pods et créer un rôle de cluster nommé privilèged-psp pour permettre l'utilisation des politiques de sécurité des pods (PSP) et l'associer à la PSP privilégiée :

 kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged

Désactivation par espace de noms :

Créez une liaison de rôle dans l'espace de noms cible pour associer le rôle de cluster privilégié-psp au groupe system:serviceaccounts:$NAMESPACE . Cette liaison accorde effectivement à tous les comptes de service au sein de l'espace de noms un accès à la PSP entièrement privilégiée, en contournant PodSecurityPolicy :

 kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE

Avec cette configuration, la PSP privilégiée ne mute pas et le contrôleur d'admission PodSecurityPolicy donne toujours la priorité aux PSP non mutantes. Par conséquent, les pods de cet espace de noms ne seront plus modifiés ou restreints par PodSecurityPolicy.

Un avantage de cette approche est sa réversibilité. Si des problèmes surviennent, vous pouvez facilement annuler la modification en supprimant le RoleBinding associé à la désactivation de PodSecurityPolicy. Assurez-vous que les politiques de sécurité des pods préexistantes restent en place pendant ce processus.

Annuler la désactivation de PodSecurityPolicy :

Pour annuler la désactivation de PodSecurityPolicy pour l'espace de noms, supprimez simplement le RoleBinding créé précédemment :

 kubectl delete -n $NAMESPACE rolebinding disable-psp

Revisitez les processus de création d’espaces de noms

Les espaces de noms existants étant mis à jour pour appliquer l'admission de sécurité des pods, il est essentiel de revoir et de mettre à jour vos processus et stratégies pour créer de nouveaux espaces de noms. Cela garantit que les nouveaux espaces de noms sont configurés avec un profil de sécurité des pods approprié dès le départ.
Considérez les étapes suivantes pour améliorer les processus de création d'espaces de noms :

1. Ajuster les politiques de création d'espaces de noms : mettez à jour les politiques et procédures de votre organisation pour créer de nouveaux espaces de noms afin d'inclure la sélection et l'application du niveau de sécurité des pods souhaité. Assurez-vous que les normes de sécurité sont établies dès la phase de création.

2. Configuration statique : vous pouvez configurer de manière statique le contrôleur d'admission Pod Security pour définir des niveaux d'application, d'audit et/ou d'avertissement par défaut pour les espaces de noms sans étiquette. Cette approche garantit que les espaces de noms dépourvus d'étiquettes explicites de sécurité des pods respectent toujours vos normes de sécurité spécifiées par défaut.

   
   

   En revisitant vos processus de création d'espaces de noms, vous pouvez intégrer de manière transparente les normes de sécurité des pods dans votre environnement Kubernetes et maintenir une approche cohérente et sécurisée dans tous les espaces de noms, anciens et nouveaux.

Désactiver la stratégie de sécurité des pods

Une fois que vous êtes sûr que le contrôleur d'admission PodSecurityPolicy (PSP) n'est plus nécessaire et que l'admission de sécurité des pods (PSA) a été implémentée et validée avec succès, vous pouvez procéder à la désactivation du contrôleur d'admission PSP.

Voici les étapes pour désactiver le contrôleur d'admission PSP :

Modifier la configuration de Kube-apiserver :

• Ouvrez le fichier de configuration de votre kube-apiserver, généralement situé dans /etc/kubernetes/manifests/kube-apiserver.yaml.
• Ajoutez l'indicateur --disable-admission-plugins pour désactiver le contrôleur d'admission PSP. Assurez-vous qu'il est supprimé de la liste des plugins d'admission actifs.

 kube-apiserver --disable-admission-plugins=PodSecurityPolicy

• Enregistrez le fichier de configuration.

Redémarrez le serveur Kube-Api :

• Redémarrez le kube-apiserver pour appliquer les modifications. Vous pouvez généralement y parvenir en redémarrant le plan de contrôle Kubernetes ou le pod kube-apiserver lui-même.

 systemctl restart kubelet

Vérification:

• Assurez-vous que le contrôleur d'admission PSP est désactivé en vérifiant les journaux kube-apiserver ou son état.

Après un « temps de trempage » suffisant pour être sûr que vous n'aurez pas besoin de revenir aux PSP, passez à l'étape suivante.

Ressources PSP de nettoyage :

Avec le contrôleur d'admission PSP désactivé et PSA en place, vous pouvez supprimer en toute sécurité vos PodSecurityPolicies existantes, ainsi que tous les rôles, ClusterRoles, RoleBindings et ClusterRoleBindings associés.

 kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true

Cette étape de nettoyage garantit qu'il n'y a aucune configuration PSP résiduelle dans votre cluster.

En désactivant le contrôleur d'admission PSP et en éliminant les ressources liées à PSP, vous simplifiez l'architecture de sécurité de votre cluster, complétant ainsi la transition vers l'admission de sécurité des pods.

Résumé

Dans ce guide complet, nous avons exploré les étapes et considérations essentielles pour une transition en douceur du cadre de sécurité de votre cluster Kubernetes des politiques de sécurité des pods (PSP) vers l'admission de sécurité des pods (PSA). Cette migration garantit que vos charges de travail continuent de s'exécuter en toute sécurité tout en s'alignant sur les normes de sécurité évolutives de Kubernetes.

Avantages et inconvénients de l'utilisation de l'admission de sécurité des pods (PSA)

Avantages:

• Composant natif Kubernetes : PSA fait partie intégrante de Kubernetes, éliminant le besoin d'installations d'outils tiers. Il exploite les fonctionnalités de sécurité intégrées de la plateforme.
• Applique les normes Kubernetes : PSA s'aligne sur les normes de sécurité natives de Kubernetes, garantissant le respect des meilleures pratiques de la plateforme.

Les inconvénients:

• Personnalisation limitée : PSA peut ne pas fournir le même niveau de personnalisation que PSP, en particulier pour les politiques de sécurité complexes qui nécessitent une mutation des spécifications du pod.
• Mise à niveau requise : les charges de travail existantes doivent être mises à jour pour inclure les paramètres de contexte de sécurité, ce qui peut nécessiter une modification des fichiers YAML.

Ce guide vous fournit les connaissances et les étapes nécessaires pour migrer en toute confiance de PSP vers PSA, garantissant une transition sécurisée et efficace tout en protégeant vos charges de travail Kubernetes. Restez à l'écoute des prochains articles, dans lesquels j'explorerai des voies de migration alternatives vers Kyverno et OPA Gatekeeper.