Migrer de PodSecurityPolicy vers le contrôleur d'admission PodSecurity

Autopilot Standard

Cette page explique comment continuer à appliquer de nombreux contrôles de sécurité au niveau du pod dans vos clusters Google Kubernetes Engine (GKE) en migrant de PodSecurityPolicy vers le contrôleur d'admission PodSecurity.

Important : GKE mettra automatiquement à niveau les clusters qui exécutent toujours la version 1.24 vers la version 1.25 lorsque la version 1.24 entrera en fin de vie le 8 janvier 2024. Nous avons repoussé la date limite du 31 octobre 2023 afin de minimiser les perturbations autour de la période des fêtes de fin d'année. Pendant cette période prolongée, nous ne fournirons des correctifs que pour les failles critiques. Pour en savoir plus sur le cycle de vie des versions mineures de GKE, consultez la page Gestion des versions et assistance pour GKE. GKE continue de suspendre les mises à niveau automatiques jusqu'au 8 janvier 2024 pour les clusters utilisant encore des API obsolètes supprimées dans la version 1.25, y compris pour les API bêta et pour PodSecurityPolicy. Nous vous recommandons de mettre à niveau vos clusters vers la version 1.25 dès que possible, car les versions mineures de GKE qui entrent en fin de vie ne reçoivent plus de correctifs de sécurité ni de corrections de bugs.

Présentation

PodSecurityPolicy était un contrôleur d'admission Kubernetes qui vous permettait d'appliquer des contrôles de sécurité au niveau du pod, tels que les normes de sécurité des pods Kubernetes, fournissant un contrôle précis de la configuration de la sécurité de vos charges de travail déployées. Le projet Kubernetes a abandonné PodSecurityPolicy et a supprimé entièrement cette fonctionnalité dans Kubernetes version 1.25.

Si vous utilisez actuellement PodSecurityPolicy dans vos clusters GKE, désactivez cette fonctionnalité avant la mise à niveau vers GKE 1.25 et versions ultérieures.

Pour en savoir plus sur l'abandon et la suppression de PodSecurityPolicy, consultez la page Obsolescence de PodSecurityPolicy.

PodSecurity et PodSecurityPolicy

Le contrôleur d'admission PodSecurity est disponible et activé par défaut sur les clusters exécutant les versions GKE suivantes :

Version 1.25 ou ultérieure : version stable
Versions 1.23 et 1.24 : version bêta

PodSecurity vous permet d'appliquer les règles définies dans les normes de sécurité des pods sur vos charges de travail déployées. PodSecurity vous permet de continuer à implémenter les configurations de sécurité recommandées au niveau du pod dans vos clusters après la migration depuis PodSecurityPolicy. Contrairement à PodSecurityPolicy, PodSecurity n'est pas compatible avec les configurations personnalisées.

Conditions requises et limites

PodSecurity est disponible en version bêta dans GKE 1.23 et 1.24, et en version stable dans GKE 1.25 et versions ultérieures.
PodSecurity ne met pas fin aux pods qui s'exécutent déjà sur vos nœuds, même s'ils enfreignent la règle appliquée.
PodSecurity ne modifie pas les champs. Si vous utilisez des champs de mutation dans votre règle PodSecurityPolicy, modifiez la spécification de pod pour vous assurer que ces champs sont présents lors du déploiement des charges de travail.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Assurez-vous de disposer d'un cluster GKE Autopilot ou standard exécutant la version 1.23 ou ultérieure.
- Pour les clusters Autopilot, inscrivez-vous à un canal de publication dans lequel la version par défaut est la version 1.23 ou ultérieure.
- Pour les clusters standards, inscrivez-vous à un canal de publication ou mettez à niveau le cluster vers une version spécifique.
Vérifiez les ressources PodSecurityPolicy pour les configurations de champs de mutation. Ajoutez ces champs à vos fichiers manifestes de pod afin que toutes les charges de travail déjà exécutées sur vos nœuds soient conformes à une règle définie dans les normes de sécurité des pods. Pour obtenir des instructions, consultez la page Simplifier et standardiser les règles de sécurité des pods.

Configurer le contrôleur d'admission PodSecurity dans votre cluster

Le contrôleur d'admission PodSecurity applique les normes de sécurité des pods au niveau de l'espace de noms. Vous devez configurer le contrôleur pour appliquer l'une des règles définies par les normes de sécurité des pods dans chaque espace de noms. Les règles suivantes sont disponibles :

Limité : règle la plus restrictive. Respecte les bonnes pratiques de renforcement des pods.
Référence : règle minimale restrictive qui empêche les élévations de privilèges connues. Autorise toutes les valeurs par défaut pour les champs dans les spécifications du pod.
Privilégié : règle sans restriction qui autorise tout, y compris les élévations de privilèges connues. Soyez prudent lorsque vous appliquez cette règle.

Pour migrer votre configuration PodSecurityPolicy vers le contrôleur d'admission PodSecurity, procédez comme suit dans chaque espace de noms de votre cluster : Ces étapes sont décrites en détail dans les sections suivantes.

Appliquez la règle Privilégié en mode dry-run à l'espace de noms et vérifiez les cas de non-respect.
Si vos pods ne respectent pas la règle Limité, appliquez la règle Référence, moins restrictive, en mode dry-run à l'espace de noms et recherchez les cas de non-respect.
Si vos pods enfreignent la règle Référence, modifiez les spécifications de votre pod pour corriger les violations.
Lorsque la règle Référence ne renvoie plus de cas de non-respect, appliquez-la en mode enforce à l'espace de noms.

Pour éviter les temps d'arrêt potentiels si PodSecurity rejette les nouveaux pods, effectuez ces étapes dans un environnement de préproduction. Vous pouvez également appliquer la règle identifiée en mode audit au lieu du mode enforce, et examiner vos journaux d'audit pour rechercher les pods potentiellement rejetés.

Le mode audit n'applique pas la règle. GKE déploie les pods et ajoute des entrées aux journaux d'audit GKE.

Répertorier tous les espaces de noms de votre cluster

Obtenez la liste de tous les espaces de noms de votre cluster. Répétez les étapes des sections suivantes pour chaque espace de noms dans la liste :

kubectl get ns

Dans les versions suivantes de GKE, GKE ignore les règles que vous appliquez à l'espace de noms kube-system :

1.23.6-gke.1900 et versions ultérieures
1.24.0-gke.1200 et versions ultérieures

Dans les versions antérieures de GKE, évitez d'appliquer des règles dans kube-system.

Appliquer chaque règle des normes de sécurité des pods en mode simulation

Dans les étapes suivantes, vous allez appliquer chaque règle en mode dry-run, en commençant par la règle Limité la plus restrictive. Si le résultat affiche un avertissement, modifiez la spécification de pod qui ne respecte pas la règle ou utilisez la règle Référence moins restrictive. Si le résultat n'affiche pas d'avertissement, vous pouvez appliquer la règle Référence sans le mode dry-run.

Appliquez la règle Limité en mode dry-run :
```
kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=restricted
```
Si un pod de l'espace de noms enfreint la règle "Limité", le résultat est semblable à celui-ci :
```
Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
namespace/NAMESPACE labeled
```
Si la règle Limité affiche un avertissement, modifiez vos pods pour corriger la violation et réexécutez la commande. Vous pouvez également essayer la règle Référence moins restrictive à l'étape suivante.

Appliquez la règle Référence en mode dry-run :

kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=baseline

Si un pod de l'espace de noms ne respecte pas la règle "Référence", le résultat est semblable à celui-ci :

Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
namespace/NAMESPACE labeled

Si vos pods enfreignent la règle "Référence", modifiez vos pods pour corriger les violations et répétez cette étape jusqu'à ce que GKE n'affiche plus d'avertissement.

Appliquer la règle dans un espace de noms

Lorsque vous identifiez la règle qui fonctionne pour un espace de noms, appliquez-la à l'espace de noms en mode enforce :

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

Remplacez POLICY par le nom de la règle, à savoir restricted, baseline ou privileged.

Veillez à répéter les étapes précédentes pour chaque espace de noms dans votre cluster.

Désactiver la fonctionnalité PodSecurityPolicy sur votre cluster

Après avoir configuré le contrôleur d'admission PodSecurity pour chaque espace de noms dans votre cluster, désactivez la fonctionnalité PodSecurityPolicy :

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

Remplacez CLUSTER_NAME par le nom de votre cluster GKE.

Lorsque vous mettez à niveau votre cluster vers la version 1.25 de GKE, celui-ci supprime automatiquement tous les objets PodSecurityPolicy restants, y compris ceux ajoutés par GKE, Config Management et les objets PodSecurityPolicy que vous avez définis précédemment.

Recommandations

Essayez de vous conformer à la règle "Limité" dans la mesure du possible. Auditez vos applications pour voir si la configuration peut être renforcée.
Vous pouvez verrouiller le mode de sécurité des pods sur une version mineure Kubernetes spécifique en ajoutant le libellé pod-security.kubernetes.io/MODE-version: VERSION aux commandes kubectl label lors des étapes précédentes. Remplacez VERSION par le numéro de version de Kubernetes, par exemple v1.24.
Une fois que vous avez désactivé la fonctionnalité PodSecurityPolicy, examinez vos applications en cours d'exécution pour rechercher d'éventuelles perturbations ou des écarts dans la configuration de la sécurité.
Une fois que vous avez configuré PodSecurity, mettez à jour votre processus de création d'espace de noms pour appliquer automatiquement un libellé PodSecurity à tous les nouveaux espaces de noms. Pour en savoir plus, consultez la section Examiner le processus de création d'un espace de noms.