Migration depuis les politiques de sécurité des pods Kubernetes : un laboratoire local sûr avec des exemples pratiques

Introduction

La migration depuis les politiques de sécurité des pods (PSP, de l'anglais Pod Security Policies) de Kubernetes est une étape critique pour les équipes exécutant Kubernetes 1.25 et les versions ultérieures, où les PSP ont été entièrement supprimées. Le remplacement, l'admission de sécurité des pods (PSA, de l'anglais Pod Security Admission), applique des normes de sécurité au niveau des espaces de noms à l'aide d'étiquettes intégrées, sans la complexité des plugins d'admission personnalisés. Cet article présente un environnement de laboratoire local sûr pour tester le flux de travail de migration avant de toucher aux clusters de production.

Nous nous concentrons sur une configuration locale utilisant Minikube ou Kind, afin que vous puissiez expérimenter sans risque. Vous apprendrez à :

• Inventorier votre utilisation actuelle des PSP.
• Configurer un cluster Kubernetes local avec une version prenant en charge la PSA.
• Créer des configurations d'admission de sécurité des pods.
• Tester les charges de travail qui étaient auparavant régies par les PSP.
• Diagnostiquer et récupérer des modes de défaillance courants.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des substituts au lieu de secrets, vérifier les résultats et documenter les procédures de récupération.

Inventaire de la version et de l'environnement

Avant toute migration, vous devez connaître l'état actuel de votre cluster. Commencez par identifier la version de Kubernetes, car les PSP ont été supprimées dans la version 1.25. Si vous utilisez les versions 1.21 à 1.24, les PSP sont dépréciées mais toujours fonctionnelles ; si vous utilisez la version 1.25 ou plus, les PSP n'existent plus. Le remplacement, l'admission de sécurité des pods, est disponible depuis la version 1.22 et stable dans la version 1.25.

Pour un laboratoire local, choisissez un outil qui correspond le plus possible à votre environnement de production. Le tableau suivant répertorie les options Kubernetes locales courantes :

Pour ce guide, nous utiliserons Minikube avec Kubernetes v1.25 pour simuler un cluster où les PSP sont supprimées, mais le processus de migration est similaire pour d'autres outils.

Vérifiez la version de votre cluster avec :

kubectl version --short
# Exemple de sortie :
# Client Version: v1.25.3
# Server Version: v1.25.3

Ensuite, inventorier les configurations existantes d'admission de sécurité des pods. Étant donné que la PSA applique des politiques à l'aide d'étiquettes d'espace de noms, vérifiez les étiquettes de sécurité sur les espaces de noms :

kubectl get namespaces --show-labels
# Recherchez les étiquettes pod-security.kubernetes.io/enforce, audit, warn.

Si vous migrez depuis un ancien cluster qui possède encore des PodSecurityPolicies, consultez le guide de migration officiel pour mapper les règles PSP existantes aux niveaux PSA avant la mise à niveau. Dans Kubernetes v1.25 et les versions ultérieures, les ressources PSP n'existent pas, alors ne tentez pas de les sauvegarder sur le nouveau cluster.

Chemin de configuration sûr

Maintenant, configurez un cluster local pour tester la migration de manière isolée. Installez Minikube s'il n'est pas déjà présent, puis démarrez un cluster avec Kubernetes v1.25 :

minikube start --kubernetes-version=v1.25.3

Vérifiez que le cluster est en cours d'exécution :

kubectl get nodes
# Sortie attendue :
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   10s   v1.25.3

Confirmez que les PSP ne sont plus disponibles :

kubectl get psp
# Sortie : error: the server doesn't have a resource type "psp"

Maintenant, activez l'admission de sécurité des pods. Dans Kubernetes v1.25, la PSA est activée par défaut et ne peut pas être désactivée. Le contrôleur d'admission utilise des étiquettes d'espace de noms pour appliquer trois niveaux de sécurité prédéfinis : privileged, baseline et restricted.

Pour tester différents niveaux, créez des espaces de noms avec les étiquettes appropriées. Par exemple, créez un espace de noms pour une charge de travail qui doit s'exécuter sans restriction (privilégiée héritée) :

kubectl create namespace privileged-apps
kubectl label namespace privileged-apps pod-security.kubernetes.io/enforce=privileged
kubectl label namespace privileged-apps pod-security.kubernetes.io/audit=privileged
kubectl label namespace privileged-apps pod-security.kubernetes.io/warn=privileged

Et un espace de noms pour une charge de travail qui doit être restreinte :

kubectl create namespace restricted-apps
kubectl label namespace restricted-apps pod-security.kubernetes.io/enforce=restricted
kubectl label namespace restricted-apps pod-security.kubernetes.io/audit=restricted
kubectl label namespace restricted-apps pod-security.kubernetes.io/warn=restricted

Explication des étiquettes :

• enforce : rejette les pods qui violent la politique.
• audit : ajoute des annotations d'audit pour les violations mais autorise le pod.
• warn : avertit l'utilisateur mais autorise le pod.

Pour une migration en douceur, commencez par les étiquettes audit et warn uniquement, observez ce qui serait rejeté, puis passez progressivement à enforce. Cela réduit les surprises.

Vérification et diagnostic

Avec le laboratoire configuré, testez comment la PSA gère différentes spécifications de pod. Créons un pod simple qui viole la politique restreinte en s'exécutant en tant que root. Tout d'abord, créez un manifeste pod-violating.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.23
    securityContext:
      runAsNonRoot: false   # Ceci viole la politique restreinte
      runAsUser: 0

Tentez de le déployer dans l'espace de noms restreint :

kubectl apply -f pod-violating.yaml -n restricted-apps

Sortie attendue (rejet) :

Error from server (Forbidden): error when creating "pod-violating.yaml": pods "privileged-pod" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod must not set securityContext.runAsNonRoot=false), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

Maintenant, déployez le même pod dans l'espace de noms privilégié :

kubectl apply -f pod-violating.yaml -n privileged-apps
# Sortie attendue : pod/privileged-pod created

Cela confirme que la PSA applique les politiques par espace de noms. Pour diagnostiquer d'autres problèmes de pod, utilisez :

kubectl describe pod <pod-name> -n <namespace>
# Recherchez la section Events pour les rejets liés à la sécurité.

Vérifiez également les journaux du pod pour vous assurer que l'application a démarré correctement :

kubectl logs privileged-pod -n privileged-apps
# Sortie attendue menant aux journaux de démarrage de nginx.

Pour un test plus réaliste, déployez un déploiement avec plusieurs réplicas et vérifiez le déploiement :

kubectl create deployment nginx-deployment --image=nginx:1.23 -n restricted-apps
# Observez le rejet si le contexte de sécurité par défaut viole la politique restreinte.
kubectl rollout status deployment/nginx-deployment -n restricted-apps

Si le déploiement échoue, inspectez les événements du déploiement :

kubectl describe deployment nginx-deployment -n restricted-apps

Cela affichera l'erreur d'admission de sécurité des pods. Pour corriger, vous devez ajuster le contexte de sécurité du pod pour se conformer à la politique restreinte, par exemple :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: restricted-apps
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: nginx
        image: nginx:1.23
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]

Appliquez et vérifiez :

kubectl apply -f deployment-fixed.yaml
kubectl rollout status deployment/nginx-deployment -n restricted-apps
# Attendu : deployment "nginx-deployment" successfully rolled out

Cette approche itérative vérifie que les charges de travail peuvent être migrées vers la base de référence restreinte.

Modes de défaillance et récupération

Pendant la migration, vous pouvez rencontrer plusieurs scénarios de défaillance courants. Voici les problèmes typiques, leurs causes et les étapes de récupération.

Pod rejeté avec « violates PodSecurity »

Cela se produit lorsque la spécification du pod ne respecte pas le niveau de sécurité de l'espace de noms. Le message d'erreur répertorie les violations spécifiques. Pour récupérer, vous pouvez :

• Ajuster le contexte de sécurité du pod pour se conformer (recommandé).
• Modifier l'étiquette de l'espace de noms vers un niveau moins restrictif si la charge de travail l'exige réellement (par exemple, privilégié pour les applications héritées).

Exemple : si un pod nécessite la capacité NET_ADMIN, la politique restreinte le rejettera. Vous pouvez déplacer le pod vers un espace de noms étiqueté baseline ou privileged, mais évaluez d'abord les implications en matière de sécurité.

PSP toujours actives dans les anciens clusters

Si vous utilisez Kubernetes v1.21-1.24, les PSP peuvent encore être activées. Pour effectuer la transition, vous pouvez exécuter la PSA parallèlement aux PSP. Activez la feature gate PSA et migrez progressivement les espaces de noms. Dans ce cas, un pod doit réussir à la fois la PSP et la PSA pour être admis. Pour minimiser les conflits, répliquez les restrictions PSP dans les étiquettes PSA.

Étiquettes d'espace de noms mal appliquées

Si les étiquettes sont manquantes ou mal orthographiées, la PSA ne sera pas appliquée comme prévu. Vérifiez les étiquettes de l'espace de noms avec :

kubectl get namespace <name> --show-labels

Vérifiez que pod-security.kubernetes.io/enforce est défini sur le niveau souhaité.

Les journaux d'audit ne montrent pas les violations

Si vous définissez uniquement l'étiquette audit, les pods sont autorisés mais des annotations d'audit sont ajoutées. Consultez les événements du pod ou les journaux d'audit (si un backend est configuré) pour voir les violations. Pour examiner les annotations d'audit sur un pod :

kubectl describe pod <pod-name> -n <namespace> | grep -A5 Annotations

Retour temporaire aux PSP

Sur les clusters prenant encore en charge les PSP, vous pouvez réappliquer les manifestes PSP précédemment exportés s'ils sont disponibles, et supprimer les étiquettes PSA des espaces de noms concernés. Sur Kubernetes v1.25 ou version ultérieure, les PSP ne peuvent pas être restaurées ; à la place, basculez temporairement l'étiquette enforce de l'espace de noms vers un niveau moins restrictif tel que baseline ou privileged pendant que vous corrigez le problème sous-jacent. Cependant, prévoyez de corriger le problème sous-jacent plutôt que de dépendre des PSP à long terme.

Pièges courants et comment les éviter

La migration des PSP vers la PSA échoue souvent en raison de plusieurs erreurs courantes. Comprendre ces pièges vous aide à éviter des temps d'arrêt coûteux.

Supposer que la politique restreinte convient à toutes les charges de travail

Le niveau restricted est le plus strict et peut casser de nombreuses applications existantes qui dépendent de root ou des capacités Linux. De nombreuses équipes étiquettent tous les espaces de noms comme restricted et provoquent des rejets massifs de pods. Pour éviter cela, commencez par les étiquettes audit et warn uniquement, analysez les violations, puis décidez du niveau approprié pour chaque espace de noms. Utilisez un déploiement progressif : d'abord audit, puis warn, puis enforce sur un sous-ensemble d'espaces de noms.

Ne pas inventorier l'utilisation des PSP avant la migration

Sans un inventaire clair, vous risquez de manquer des charges de travail critiques. Utilisez des outils comme kubectl psp-migrate (de l'équipe sig-auth de Kubernetes) ou des scripts pour répertorier les pods qui référencent des PSP. Si vos pods utilisent des comptes de service, vérifiez les liaisons de rôles qui accordent l'utilisation des PSP. Un inventaire approfondi est essentiel pour une transition en douceur.

Ignorer la différence entre les niveaux PSA et les fonctionnalités PSP

Les PSP avaient de nombreux contrôles, tels que les chemins d'hôte autorisés, les FlexVolumes autorisés et les profils seccomp par défaut. Les niveaux PSA ne couvrent pas tous les champs PSP ; pour des contrôles avancés, vous devrez peut-être utiliser d'autres contrôleurs d'admission comme Kyverno ou OPA Gatekeeper. Ne supposez pas que PSP et PSA sont équivalents. Mappez vos exigences PSP aux niveaux PSA et identifiez les lacunes.

Appliquer des changements de politique sans tester dans un laboratoire

Tester en production est dangereux. Utilisez toujours un laboratoire local ou un cluster de staging pour valider les étapes de migration. L'environnement de laboratoire décrit dans cet article vous permet d'expérimenter en toute sécurité. Répliquez vos charges de travail de production dans le laboratoire et testez avec des configurations représentatives.

Ne pas mettre à jour les pipelines CI/CD

Les pipelines qui déploient des pods avec d'anciens contextes de sécurité échoueront après la migration vers la PSA. Mettez à jour vos modèles CI/CD pour inclure des contextes de sécurité conformes. Analysez également vos images de conteneurs pour vérifier leur conformité aux politiques restreintes à l'aide d'outils comme kube-score ou polaris.

Liste de contrôle des opérations

Utilisez la liste de contrôle suivante pour guider votre processus de migration. Attribuez un responsable pour chaque élément et une fréquence de révision.

Attribuer un seul responsable garantit une responsabilité claire. Passez en revue les progrès lors de réunions de migration hebdomadaires et ajustez le plan si nécessaire.

Conclusion

La migration des politiques de sécurité des pods de Kubernetes vers l'admission de sécurité des pods est une étape nécessaire pour les clusters sous Kubernetes 1.25 et les versions ultérieures. En utilisant un laboratoire local, vous pouvez tester le processus en toute sécurité, identifier les problèmes potentiels et former votre équipe avant les changements en production.

Dans cet article, nous avons couvert :

• L'inventaire de votre cluster actuel et des PSP.
• La configuration d'un cluster local avec Minikube.
• La configuration des étiquettes d'espace de noms pour les niveaux PSA.
• Le test de la conformité des pods et le diagnostic des erreurs.
• La gestion des modes de défaillance et des pièges courants.
• La fourniture d'une liste de contrôle des opérations avec des responsables.

Ensuite, choisissez une vérification à faible risque dans la liste de contrôle, exécutez-la dans votre laboratoire et documentez les résultats. Cette approche incrémentale rendra votre migration moins stressante et plus réussie. N'oubliez pas que l'objectif n'est pas seulement de supprimer les PSP, mais d'adopter une posture de sécurité robuste avec l'admission de sécurité des pods et des outils complémentaires si nécessaire.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision.