Migrer depuis Policy Controller

Autopilot Standard

Ce document explique comment migrer vos règles d'admission depuis Policy Controller afin de réduire le risque de lacunes dans l'application des règles. Policy Controller est obsolète depuis le 12 novembre 2026 et ne sera plus pris en charge à partir du 31 décembre 2027. Dans la version 1.39 et les versions ultérieures, les clusters Google Kubernetes Engine (GKE) ne sont pas compatibles avec Policy Controller.

Vous pouvez migrer les règles d'admission que vous appliquez à l'aide de Policy Controller vers des règles ValidatingAdmissionPolicies Kubernetes ou vers un Open Policy Agent (OPA) Gatekeeper autogéré. La migration n'affecte pas les charges de travail déjà en cours d'exécution. Policy Controller évalue les requêtes de création ou de mise à jour de ressources. Par conséquent, sa suppression ne redémarre pas et ne modifie pas les charges de travail en cours d'exécution.

Ce document s'adresse aux opérateurs et aux spécialistes de la sécurité qui gèrent Policy Controller sur un parc. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Mises à niveau bloquées vers GKE version 1.39

GKE bloque les mises à niveau vers la version 1.39 et les versions ultérieures pour les clusters sur lesquels Policy Controller est installé. Avant de mettre à niveau un cluster vers la version 1.39, migrez vos règles et supprimez Policy Controller de ce cluster. Ne supprimez pas Policy Controller simplement pour débloquer la mise à niveau avant de migrer vos règles, car cela laisserait le cluster sans application de règles.

Choisir une autre photo

Évaluez chaque règle d'admission dans Policy Controller et choisissez une option de remplacement pour cette règle dans le tableau suivant. Vous n'avez pas besoin de choisir un seul remplacement pour l'ensemble d'un cluster. Vous pouvez combiner des options sur le même cluster en fonction des exigences de chaque règle :

Comparaison des options de remplacement de Policy Controller

Option	Cas d'utilisation	Exploitation et assistance
ValidatingAdmissionPolicy (recommandé)	Règles qui vérifient une seule ressource lors de sa création ou de sa mise à jour. La plupart des modèles de la bibliothèque de modèles Policy Controller fonctionnent de cette manière.	Les ValidatingAdmissionPolicies sont intégrées à Kubernetes et disponibles dans GKE version 1.30 et ultérieure sans frais supplémentaires. Cloud Customer Care est compatible avec ValidatingAdmissionPolicies dans le cadre de GKE.
Admission de sécurité des pods (recommandé pour les bundles de sécurité des pods)	Contrôles de sécurité des pods prédéfinis à partir du bundle pss-baseline-v2022, pss-restricted-v2022 ou psp-v2022. Pour en savoir plus, consultez Utiliser l'admission de sécurité des pods pour les bundles de sécurité des pods.	L'admission de sécurité des pods est intégrée à Kubernetes et activée par défaut dans GKE sans frais supplémentaires. Le service client est compatible avec l'admission de sécurité des pods dans le cadre de GKE.
OPA Gatekeeper autogéré	Les règles que ValidatingAdmissionPolicies ne peut pas exprimer, telles que les règles référentielles qui lisent d'autres ressources du cluster, les règles que vous souhaitez conserver dans Rego et les audits des ressources existantes. Vous pouvez également ajouter des règles CEL (Common Expression Language) aux modèles ConstraintTemplates de Gatekeeper afin que Gatekeeper génère des règles ValidatingAdmissionPolicies pour l'application du serveur d'API, et que son contrôleur d'audit vérifie les ressources existantes.	Vous installez, mettez à niveau et utilisez Gatekeeper. Le service client n'est pas compatible avec Gatekeeper Open Source. La communauté Gatekeeper fournit une assistance via GitHub.

Inventorier et classer vos règles

Par défaut, la bibliothèque de modèles Policy Controller installe tous les modèles, et les bundles de règles installent leurs contraintes avec la mesure coercitive dryrun. Par conséquent, les modèles et les contraintes d'un cluster ne correspondent pas nécessairement aux règles que vous appliquez. Pour savoir ce que vous appliquez, procédez comme suit :

1. Identifiez les clusters de votre parc qui exécutent Policy Controller :

   gcloud container fleet policycontroller describe \
       --project=PROJECT_ID
   

   Remplacez PROJECT_ID par l'ID de votre projet hôte de parc.

   Remarque : Il est possible que des clusters exécutant Policy Controller se trouvent en dehors d'un parc, par exemple des clusters sur lesquels vous avez installé Policy Controller à l'aide de l'opérateur ConfigManagement ou des clusters dont vous avez annulé l'enregistrement dans un parc sans désinstaller Policy Controller. Ces clusters n'apparaissent pas dans le résultat de la commande précédente. Pour vérifier si un cluster exécute Policy Controller, consultez Afficher la version de Policy Controller. Pour supprimer Policy Controller de ces clusters, consultez Supprimer Policy Controller des clusters en dehors d'un parc.

2. Sur chaque cluster que vous avez identifié, listez vos contraintes :

   kubectl get constraints \
       -o custom-columns='KIND:.kind,NAME:.metadata.name,'\
   'ACTION:.spec.enforcementAction,VIOLATIONS:.status.totalViolations,'\
   'BUNDLE:.metadata.labels.policycontroller\.gke\.io/bundleName'
   

   Le résultat affiche la mesure coercitive de chaque contrainte, le nombre de cas de non-respect de la contrainte lors de l'audit le plus récent et tout bundle qui l'a installée. Une contrainte qui n'a pas de valeur dans la colonne ACTION utilise l'action d'application deny par défaut.

3. Sauvegardez vos ConstraintTemplates et vos contraintes dans des fichiers distincts :

   kubectl get constrainttemplates -o yaml \
       > policy-controller-templates-backup.yaml
   kubectl get constraints -o yaml \
       > policy-controller-constraints-backup.yaml
   

4. Facultatif : effectuez les opérations de sauvegarde supplémentaires suivantes :

   • Si vous avez activé les règles référentielles dans Policy Controller, sauvegardez votre configuration de synchronisation :

     kubectl get config.config.gatekeeper.sh -n gatekeeper-system -o yaml \
         > policy-controller-config-backup.yaml
     

   • Si vous avez activé la mutation dans Policy Controller, sauvegardez vos mutateurs :

     kubectl get assign,assignmetadata,assignimage,modifyset -o yaml \
         > policy-controller-mutators-backup.yaml
     

Conservez ces fichiers de sauvegarde dans un endroit sûr. La suppression de Policy Controller supprime tous les objets ConstraintTemplate, les contraintes, les configurations de synchronisation et les mutateurs du cluster, y compris ceux que vous avez créés. Vous avez besoin des sauvegardes pour traduire ou recréer vos règles.

Après avoir sauvegardé vos règles, déterminez votre chemin de migration pour chaque contrainte en vérifiant le type de contrainte dans le tableau suivant :

Chemins de migration par type de contrainte

Type de contrainte	Processus de migration
Contrainte de ressource unique	Si une contrainte évalue les champs uniquement sur la ressource entrante sans lire data.inventory ni appartenir à un bundle de sécurité de pod, utilisez une règle ValidatingAdmissionPolicy.
Contrainte dryrun non appliquée	Si une contrainte utilise la mesure coercitive dryrun et que vous ne prévoyez pas de l'appliquer, supprimez-la.
Contrainte du bundle de sécurité des pods	Si une contrainte provient du lot pss-baseline-v2022, pss-restricted-v2022 ou psp-v2022, utilisez Pod Security Admission. Utilisez ValidatingAdmissionPolicies pour tous les contrôles non couverts par Pod Security Admission.
Contrainte référentielle	Si une contrainte utilise un modèle référentiel qui lit d'autres ressources du cluster, utilisez Gatekeeper autogéré. Pour trouver des modèles référentiels, recherchez la référence data.inventory dans votre fichier de sauvegarde.
Contrainte Cloud Service Mesh, Istio ou Google Cloud	Examinez la contrainte individuellement pour vérifier si une fonctionnalité GKE intégrée remplace la règle ou si le ConstraintTemplate de votre fichier de sauvegarde indique data.inventory. La plupart de ces modèles ne vérifient que la ressource entrante et fonctionnent dans ValidatingAdmissionPolicies, à l'exception des modèles référentiels AsmAuthzPolicyDefaultDeny et AsmPeerAuthnMeshStrictMtls, qui nécessitent un Gatekeeper autogéré. Pour les remplacements intégrés, activez l'autorisation binaire au lieu d'utiliser le ConstraintTemplate K8sRequireBinAuthZ, et configurez l'image de nœud de vos pools de nœuds au lieu d'utiliser le ConstraintTemplate K8sRequireCosNodeImage.

Migrer vers ValidatingAdmissionPolicy

Une ressource ValidatingAdmissionPolicy contient la logique de la règle, comme un modèle de contrainte (ConstraintTemplate). Un objet ValidatingAdmissionPolicyBinding applique la règle, comme une contrainte. Une ressource ValidatingAdmissionPolicy utilise des expressions CEL au lieu de Rego, et le serveur d'API évalue les expressions directement, sans webhook.

Exemple : dépôts d'images autorisés

La contrainte Policy Controller suivante exige que les pods utilisent des images d'un dépôt Artifact Registry. Il exclut l'espace de noms kube-system :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
  parameters:
    repos:
    - "us-docker.pkg.dev/example-project/example-repo/"

Les ressources ValidatingAdmissionPolicy et ValidatingAdmissionPolicyBinding suivantes appliquent la même règle. Le ValidatingAdmissionPolicyBinding utilise les actions Warn et Audit pour vous permettre de comparer les résultats avant d'appliquer la ValidatingAdmissionPolicy :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-repos
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods", "pods/ephemeralcontainers"]
  variables:
  - name: repos
    expression: "['us-docker.pkg.dev/example-project/example-repo/']"
  - name: images
    expression: >-
      object.spec.containers.map(c, c.image) +
      (has(object.spec.initContainers) ?
        object.spec.initContainers.map(c, c.image) : []) +
      (has(object.spec.ephemeralContainers) ?
        object.spec.ephemeralContainers.map(c, c.image) : [])
  validations:
  - expression: >-
      variables.images.all(image,
        variables.repos.exists(repo, image.startsWith(repo)))
    messageExpression: >-
      'container images must come from one of these repositories: ' +
      variables.repos.join(', ')
    reason: Forbidden
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-repos
spec:
  policyName: allowed-repos
  validationActions: ["Warn", "Audit"]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system", "gatekeeper-system"]

Dans cet exemple, la variable repos contient la valeur du champ parameters de la contrainte. L'expression de validation renvoie une valeur true pour les pods conformes à la règle ValidatingAdmissionPolicy, ce qui est l'inverse d'une règle de non-conformité Rego. Pour réutiliser une ressource ValidatingAdmissionPolicy sur plusieurs ressources ValidatingAdmissionPolicyBinding qui fournissent des valeurs différentes, utilisez une ressource de paramètre au lieu d'une variable. Pour en savoir plus sur les ressources de paramètres, consultez Ressources de paramètres dans la documentation Kubernetes.

Le tableau suivant montre comment les champs de contrainte sont mappés aux champs ValidatingAdmissionPolicy et ValidatingAdmissionPolicyBinding :

Mappage des champs de contrainte Policy Controller aux champs ValidatingAdmissionPolicy et ValidatingAdmissionPolicyBinding

Champ de contrainte	Champ ValidatingAdmissionPolicy ou ValidatingAdmissionPolicyBinding
spec.enforcementAction	Le champ validationActions dans ValidatingAdmissionPolicyBinding, qui mappe les actions deny, warn et dryrun aux valeurs ["Deny"], ["Warn"] et ["Audit"].
spec.parameters	Le champ variables dans ValidatingAdmissionPolicy ou une ressource de paramètre référencée par ValidatingAdmissionPolicyBinding dans le champ paramRef
spec.match.kinds	Le champ matchConstraints.resourceRules dans ValidatingAdmissionPolicy, qui utilise des groupes d'API et des noms de ressources, tels que la ressource pods, au lieu de genres
spec.match.namespaces et spec.match.excludedNamespaces	Le champ matchResources.namespaceSelector dans ValidatingAdmissionPolicyBinding, à l'aide de l'opérateur In ou NotIn sur l'étiquette kubernetes.io/metadata.name
spec.match.labelSelector	Le champ matchResources.objectSelector dans ValidatingAdmissionPolicyBinding
spec.match.namespaceSelector	Le champ matchResources.namespaceSelector dans ValidatingAdmissionPolicyBinding
spec.match.scope	Le champ scope de chaque règle de ressource

Pour en savoir plus sur l'écriture d'expressions, consultez CEL dans Kubernetes dans la documentation Kubernetes.

Tester des règles avec Policy Controller

Pour remplacer une contrainte sans interruption de l'application, exécutez la règle ValidatingAdmissionPolicy à côté de la contrainte avant d'appliquer la règle ValidatingAdmissionPolicy :

1. Appliquez la règle ValidatingAdmissionPolicy et une liaison ValidatingAdmissionPolicyBinding avec le paramètre validationActions: ["Warn", "Audit"]. Laissez la contrainte Policy Controller en place.
2. Comparez les résultats à l'aide de la requête de journal d'audit dans Remplacer les rapports de non-conformité. Si la ressource ValidatingAdmissionPolicy signale des requêtes que Policy Controller autorise, ou inversement, corrigez la ressource ValidatingAdmissionPolicy. Pour les ValidatingAdmissionPolicies qui correspondent à des pods, ne vous fiez pas aux avertissements. Les contrôleurs créent les pods pour les déploiements et d'autres charges de travail. Le contrôleur reçoit donc l'avertissement.
3. Une fois que les résultats correspondent, modifiez ValidatingAdmissionPolicyBinding pour utiliser le paramètre validationActions: ["Deny"].
4. Supprimez la contrainte Policy Controller.

Planifier les différences de comportement

Les ValidatingAdmissionPolicies se comportent différemment de Policy Controller de la manière suivante, ce qui peut bloquer les requêtes ou laisser des lacunes dans l'application :

• Règle d'échec : le webhook Policy Controller échoue, ce qui signifie que le serveur d'API accepte une requête si Policy Controller ne répond pas. Une ressource ValidatingAdmissionPolicy dont le paramètre est défini sur failurePolicy: Fail refuse une requête si une expression renvoie une erreur ou dépasse la limite de coût CEL. La règle ValidatingAdmissionPolicy refuse également une requête si une ressource de paramètre référencée n'existe pas et que la valeur du champ paramRef.parameterNotFoundAction dans ValidatingAdmissionPolicyBinding est Deny. Si la valeur est Allow, le serveur d'API ignore une ressource de paramètre manquante, quel que soit le paramètre failurePolicy. Testez chaque ValidatingAdmissionPolicy et choisissez des valeurs pour les deux champs.
• Champs manquants : Rego traite un champ manquant comme une absence de non-conformité, mais CEL renvoie une erreur. Avant de lire un champ facultatif, utilisez la macro has() pour vérifier si le champ existe.
• Exemptions : une ValidatingAdmissionPolicy n'exempte pas les espaces de noms par défaut et n'utilise pas l'étiquette admission.gatekeeper.sh/ignore. Sur les clusters GKE Standard, un ValidatingAdmissionPolicyBinding s'applique à tous les espaces de noms du cluster, y compris les espaces de noms système tels que l'espace de noms kube-system, sauf si vous les excluez dans le champ matchResources.namespaceSelector du ValidatingAdmissionPolicyBinding ou dans les champs matchConstraints.namespaceSelector ou matchConditions du ValidatingAdmissionPolicy. Sur les clusters Autopilot, GKE exclut automatiquement les espaces de noms gérés et rejette les ValidatingAdmissionPolicies qui correspondent aux ressources nodes, persistentVolumes, certificatesigningrequests ou tokenreviews. Pour en savoir plus, consultez Mesures de sécurité de GKE Autopilot.
• Sous-ressources : Policy Controller vérifie les mises à jour de pods qui ajoutent des conteneurs éphémères. Pour conserver cette couverture, incluez la sous-ressource pods/ephemeralcontainers dans vos règles de ressources, comme dans l'exemple.
• Aucun audit des ressources existantes : une règle ValidatingAdmissionPolicy n'évalue que les requêtes entrantes du serveur d'API. Il ne signale pas les ressources existantes qui ne respectent pas une règle ValidatingAdmissionPolicy.
• Un message pour chaque requête : une règle ValidatingAdmissionPolicy signale la première validation qui échoue, et non chaque cas de non-respect.

Utiliser Pod Security Admission pour les bundles de sécurité des pods

Si vous utilisez les bundles pss-baseline-v2022 ou pss-restricted-v2022, remplacez-les par Pod Security Admission au lieu de traduire chaque contrainte. L'admission de sécurité des pods utilise le contrôleur d'admission Kubernetes PodSecurity intégré pour appliquer des règles prédéfinies issues des normes de sécurité des pods Kubernetes en fonction des libellés d'espace de noms. Le bundle pss-baseline-v2022 correspond au niveau baseline et le bundle pss-restricted-v2022 au niveau restricted.

L'admission de sécurité des pods ne couvre pas tous les contrôles du bundle psp-v2022, tels que les listes d'autorisation pour les chemins d'hôte, les utilisateurs, les fonctionnalités et les sysctls. Utilisez ValidatingAdmissionPolicies pour ces contrôles. Pod Security Admission ne peut pas non plus exclure des images spécifiques, comme les contraintes Policy Controller qui utilisent le paramètre exemptImages. GKE n'est pas compatible avec la configuration des exemptions d'admission de sécurité des pods. Si vous avez besoin d'exceptions, utilisez ValidatingAdmissionPolicies pour les règles concernées.

Pour en savoir plus sur la configuration de l'admission de sécurité des pods, consultez Appliquer des règles de sécurité prédéfinies au niveau du pod à l'aide de PodSecurity.

Migrer vers OPA Gatekeeper autogéré

Choisissez Gatekeeper pour les règles que ValidatingAdmissionPolicies ne peut pas exprimer. Policy Controller est basé sur Gatekeeper. Vos objets ConstraintTemplates et vos contraintes utilisent donc les mêmes API dans Gatekeeper. Tous les modèles de la bibliothèque de modèles Policy Controller fonctionnent dans Gatekeeper sans modification de leur logique. Toutefois, Gatekeeper utilise un moteur Rego plus récent et une validation plus stricte qui peut rejeter un modèle ConstraintTemplate personnalisé.

Lorsque vous utilisez Gatekeeper autogéré, vous devenez responsable des tâches queGoogle Cloud effectue pour Policy Controller, telles que l'installation, la mise à niveau, le scaling et la surveillance de Gatekeeper sur chaque cluster. Le service client ne prend pas en charge Gatekeeper Open Source. Pour obtenir de l'aide, utilisez l'outil de suivi des problèmes Gatekeeper sur GitHub.

Gatekeeper n'inclut pas la bibliothèque de modèles ni les groupes de règles Policy Controller. Vos fichiers de sauvegarde contiennent les ConstraintTemplates et les contraintes de vos clusters. Pour les modèles provenant de la bibliothèque Gatekeeper Open Source, vous pouvez utiliser les modèles de la bibliothèque de règles Gatekeeper. Les noms des modèles restent les mêmes, mais les paramètres et les messages peuvent différer d'une version à l'autre.

Pour déplacer des règles vers Gatekeeper, procédez comme suit :

1. Facultatif : Si vous ne pouvez pas accepter d'interruption de l'application pendant le remplacement de Policy Controller, migrez d'abord vos règles les plus importantes vers ValidatingAdmissionPolicies. Assurez-vous que ces ValidatingAdmissionPolicyBindings excluent l'espace de noms gatekeeper-system afin qu'ils ne bloquent pas les jobs d'installation de Gatekeeper. Une fois Policy Controller supprimé, votre cluster cesse d'appliquer les règles Gatekeeper jusqu'à ce que vous appliquiez les contraintes Gatekeeper correspondantes. Les ValidatingAdmissionPolicies continuent d'être appliquées, car elles ne dépendent pas de Policy Controller ni de Gatekeeper.

2. Si vous utilisez des modèles ConstraintTemplates personnalisés, testez chaque fichier manifeste de modèle personnalisé à l'aide de l'outil de ligne de commande gator de la version de Gatekeeper que vous prévoyez d'installer :

   gator test --filename=TEMPLATE_FILE
   

   Remplacez TEMPLATE_FILE par le chemin d'accès à votre fichier manifeste ConstraintTemplate. Avant de supprimer Policy Controller, corrigez tout modèle ConstraintTemplate personnalisé rejeté par Gatekeeper.

3. Si vous déployez des contraintes à partir d'un dépôt Git à l'aide d'un outil GitOps, préparez les ConstraintTemplates que vos contraintes utilisent et ajoutez-les au dépôt lorsque vous installez Gatekeeper. Sinon, vos contraintes ne s'appliqueront pas après la suppression de Policy Controller, car leurs ConstraintTemplates n'existeront plus.

4. Supprimez Policy Controller en suivant les étapes de la section Supprimer Policy Controller. N'installez pas Gatekeeper sur un cluster qui exécute toujours Policy Controller. Ils utilisent tous deux l'espace de noms gatekeeper-system, les mêmes CustomResourceDefinitions et les mêmes noms de webhook.

5. Installez Gatekeeper à l'aide de Helm, en utilisant les paramètres que vous choisissez dans le tableau de la section suivante, Paramètres Gatekeeper qui diffèrent de Policy Controller. Pour en savoir plus sur l'installation de Gatekeeper, consultez la section Installation de la documentation de Gatekeeper.

   Sur les clusters Autopilot, l'installation par défaut du chart Helm échoue, car GKE rejette les règles génériques dans les webhooks de mutation. Définissez la valeur Helm disableMutation: true ou la valeur Helm mutatingWebhookCustomRules pour lister uniquement les ressources spécifiques ciblées par vos mutateurs. N'incluez pas les ressources nodes, persistentvolumes, certificatesigningrequests ou tokenreviews.

6. Dans vos fichiers de sauvegarde, supprimez les champs, étiquettes et annotations suivants de chaque ressource que vous prévoyez de réappliquer :

   • Le champ status.
   • Les champs resourceVersion, uid, creationTimestamp, generation, managedFields et ownerReferences de la section metadata.
   • L'annotation kubectl.kubernetes.io/last-applied-configuration.
   • L'étiquette app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com. Si Policy Controller est réactivé sur le cluster, par exemple par une configuration par défaut au niveau du parc, il gère les ressources portant ce libellé et peut les modifier ou les supprimer.
   • Étiquettes et annotations dont les clés ont le préfixe policycontroller..

7. Appliquez les ConstraintTemplates utilisés par vos contraintes, puis vérifiez que Gatekeeper a créé une CustomResourceDefinition pour chaque modèle :

   kubectl get constrainttemplates \
       -o custom-columns='NAME:.metadata.name,CREATED:.status.created'
   

   Lorsque chaque modèle affiche une valeur true dans la colonne CREATED, appliquez vos contraintes.

Paramètres Gatekeeper différents de Policy Controller

Avant d'installer Gatekeeper, examinez les paramètres du tableau suivant, dans lequel les valeurs par défaut du chart Helm Gatekeeper diffèrent de celles de Policy Controller :

Comparaison des valeurs par défaut de Policy Controller et des valeurs par défaut du chart Helm Gatekeeper

Paramètre	Policy Controller par défaut	Chart Helm Gatekeeper par défaut	Recommandation
Mutation	Désactivé, sauf si vous l'avez activé	Activé	Si vous n'utilisez pas de mutation, définissez la valeur Helm disableMutation: true. Sur les clusters Autopilot, vous devez définir la valeur Helm disableMutation: true ou configurer la valeur Helm mutatingWebhookCustomRules sans caractères génériques ni ressources restreintes. Si vous ne spécifiez pas l'une de ces valeurs, GKE rejette l'installation.
Exempter des espaces de noms	L'espace de noms gatekeeper-system et les espaces de noms de votre liste exemptableNamespaces	Espace de noms dans lequel Gatekeeper est installé	Ajoutez vos espaces de noms exemptés à la valeur Helm controllerManager.exemptNamespaces. Gatekeeper rejette les modifications apportées aux espaces de noms portant l'étiquette admission.gatekeeper.sh/ignore, sauf si ces espaces de noms sont exemptés.
Données référentielles	Synchronisation automatique pour les bundles référentiels	Non synchronisé	Créez une configuration Gatekeeper ou un SyncSet qui liste les types lus par vos modèles référentiels. Tant que ces types ne sont pas synchronisés dans l'objet data.inventory, les vérifications de conflit autorisent les requêtes non conformes, et les vérifications d'existence, telles que le modèle de contrainte K8sRequireNamespaceNetworkPolicies, refusent chaque requête correspondante, même lorsque la ressource requise existe.
Génération de ValidatingAdmissionPolicy	Non disponible	Activé pour les modèles contenant du code CEL	Les modèles Policy Controller ne contiennent que du code Rego. Par conséquent, Gatekeeper ne génère des ValidatingAdmissionPolicies que si vous ajoutez du code CEL à vos ConstraintTemplates. Pour conserver l'application dans le webhook, définissez les valeurs Helm defaultCreateVAPForTemplates: false et defaultCreateVAPBindingForConstraints: false. Pour en savoir plus, consultez Intégration à la règle d'admission de validation Kubernetes dans la documentation de Gatekeeper.
Instances répliquées et ressources	Une instance répliquée pour chaque composant, avec une limite de mémoire de 1 024 Mio	Trois instances répliquées de webhook, avec des limites de ressources différentes	Configurez le nombre d'instances répliquées et les limites de ressources en fonction de votre utilisation actuelle.
Images	Extraite d'un registre géré par Google	Extraites de Docker Hub (images openpolicyagent/gatekeeper, openpolicyagent/gatekeeper-crds et curlimages/curl)	Pour les clusters privés ou les clusters qui appliquent l'autorisation binaire, dupliquez les trois images dans Artifact Registry et remplacez leurs valeurs d'image dans le graphique. Si vous ne dupliquez pas l'image curlimages/curl, désactivez le job de vérification du webhook.

Par défaut, Gatekeeper n'expose que les métriques Prometheus, et leurs noms diffèrent de ceux que Policy Controller envoie à Cloud Monitoring. Mettez à jour les tableaux de bord et les alertes qui utilisent les métriques Policy Controller.

Migrer les règles de mutation

Si vous avez activé la mutation dans Policy Controller, listez vos mutateurs :

kubectl get assign,assignmetadata,assignimage,modifyset

Pour chaque mutateur, choisissez l'une des options suivantes :

• MutatingAdmissionPolicy : vous pouvez utiliser une MutatingAdmissionPolicy dans GKE version 1.36 et ultérieure. Comme une ressource ValidatingAdmissionPolicy, une ressource MutatingAdmissionPolicy utilise des expressions CEL et s'exécute dans le serveur d'API sans webhook. Kubernetes exécute toutes les MutatingAdmissionPolicies avant les ValidatingAdmissionPolicies. Testez-les donc ensemble pour vous assurer qu'une mutation n'entraîne pas le rejet d'un fichier manifeste valide par une ValidatingAdmissionPolicy. Sur les clusters Autopilot, GKE exclut les espaces de noms gérés des MutatingAdmissionPolicies. Pour en savoir plus sur les règles de mutation, consultez Règle d'admission de mutation dans la documentation Kubernetes.
• Gatekeeper autogéré : sur les clusters standards, vos mutateurs fonctionnent sans modification, car Gatekeeper active la mutation par défaut. Sur les clusters Autopilot, vous devez définir la valeur Helm mutatingWebhookCustomRules dans le chart Gatekeeper pour lister les ressources spécifiques ciblées par vos mutateurs au lieu de règles génériques. Pour en savoir plus, consultez Mesures de sécurité de GKE Autopilot. Après avoir installé Gatekeeper, supprimez les métadonnées Policy Controller de votre fichier de sauvegarde de mutateurs et réappliquez vos mutateurs, comme vous le faites pour les contraintes.

Mettre à jour les vérifications de règles dans les pipelines de compilation

Votre pipeline de compilation peut vérifier les fichiers manifestes par rapport à vos contraintes Policy Controller avant le déploiement. Par exemple, le pipeline peut utiliser la fonction gatekeeper dans kpt ou l'outil de ligne de commande gator. Pour en savoir plus, consultez Valider des applications par rapport aux règles de l'entreprise dans un pipeline de CI.

Si votre pipeline vérifie les fichiers manifestes, mettez-le à jour pour votre remplacement :

• Si vous utilisez Gatekeeper, vous pouvez conserver votre pipeline. Mettez à jour les chemins d'accès aux fichiers ou aux répertoires dans votre commande gator ou kpt pour référencer le dépôt ou le répertoire contenant vos fichiers manifestes ConstraintTemplate et de contrainte Gatekeeper nettoyés.

• Si vous utilisez ValidatingAdmissionPolicies, ces outils n'évaluent pas vos règles. Exécutez plutôt une simulation côté serveur sur un cluster de test qui contient vos ValidatingAdmissionPolicies et ValidatingAdmissionPolicyBindings qui utilisent l'action Deny :

  kubectl apply --dry-run=server -f MANIFEST_DIRECTORY
  

  Remplacez MANIFEST_DIRECTORY par le répertoire contenant vos fichiers manifestes. La commande échoue si une règle ValidatingAdmissionPolicy rejette un fichier manifeste.

Remplacement des rapports de non-respect des règles

Une ressource ValidatingAdmissionPolicy n'inclut pas de tableau de bord et n'audite pas les ressources qui existent déjà dans votre cluster. Utilisez plutôt les méthodes suivantes :

• Avertissements : si une liaison ValidatingAdmissionPolicyBinding utilise l'action Warn, le serveur d'API renvoie un avertissement au client qui a envoyé la requête, tel que l'outil de ligne de commande kubectl. Pour les pods créés par un contrôleur, tels que les pods d'un déploiement, le contrôleur reçoit l'avertissement.

• Journaux d'audit : si un ValidatingAdmissionPolicyBinding utilise l'action Audit, le serveur d'API annote l'entrée de journal d'audit pour chaque échec de validation. GKE écrit les requêtes de création, de mise à jour et de suppression dans les journaux d'audit des activités d'administration dans Cloud Logging. Pour trouver les validations ayant échoué, exécutez la requête suivante dans l'explorateur de journaux :

  resource.type="k8s_cluster"
  logName:"cloudaudit.googleapis.com%2Factivity"
  labels."validation.policy.admission.k8s.io/validation_failure":*
  

Si vous utilisez des contraintes qui ont la mesure coercitive dryrun comme rapport de conformité sur les ressources existantes, ValidatingAdmissionPolicies ne peut pas remplacer ce rapport. Conservez ces règles sur un Gatekeeper autogéré, dont le contrôleur d'audit vérifie les ressources existantes selon un calendrier.

Supprimer Policy Controller

Avant de supprimer Policy Controller d'un cluster, effectuez les tâches suivantes :

• Vérifiez que toutes les règles que vous avez migrées vers ValidatingAdmissionPolicies ou Pod Security Admission sont appliquées et que vous disposez d'une sauvegarde de vos ConstraintTemplates, contraintes et mutateurs. La suppression de Policy Controller supprime ses CustomResourceDefinitions, ce qui supprime tous les objets ConstraintTemplate, les contraintes et les mutateurs du cluster, y compris ceux que vous avez créés.
• Si vous déployez des contraintes à partir d'un dépôt Git à l'aide d'un outil GitOps tel que Config Sync ou Argo CD, supprimez les contraintes remplacées du dépôt. Vérifiez que les contraintes ont été supprimées de vos clusters.
• Facultatif : Pour confirmer que rien ne dépend du webhook Policy Controller, suspendez d'abord Policy Controller. La suspension ne supprime que les configurations de webhook, et vous pouvez les restaurer.

Pour supprimer Policy Controller, procédez comme suit :

1. Désinstallez Policy Controller de vos clusters :

   gcloud container fleet policycontroller disable \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID
   

   Remplacez les éléments suivants :

   • MEMBERSHIP_NAME : nom de l'appartenance du cluster enregistré duquel vous souhaitez désinstaller Policy Controller. Pour désinstaller Policy Controller de plusieurs clusters, spécifiez une liste de noms d'appartenance séparés par une virgule ou remplacez l'option --memberships=MEMBERSHIP_NAME par l'option --all-memberships.
   • PROJECT_ID : l'ID de votre projet hôte de parc

2. Vérifiez que Policy Controller a bien été désinstallé de vos clusters :

   gcloud container fleet policycontroller describe \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       --format="yaml(membershipStates)"
   

   Attendez que la valeur du champ policycontroller.state de premier niveau pour chaque appartenance soit NOT_INSTALLED, et non DECOMMISSIONING. Les entrées componentStates individuelles atteignent l'état NOT_INSTALLED avant la fin du nettoyage de CustomResourceDefinition.

   Si vous prévoyez d'installer Gatekeeper autogéré, vérifiez que l'espace de noms gatekeeper-system n'existe plus :

   kubectl get namespace gatekeeper-system
   

   Attendez que la sortie indique que l'espace de noms gatekeeper-system est introuvable.

3. Facultatif : Pour empêcher les clusters que vous enregistrerez ultérieurement d'obtenir Policy Controller, supprimez la configuration par défaut au niveau du parc :

   gcloud container fleet policycontroller enable \
       --no-fleet-default-member-config \
       --project=PROJECT_ID
   

   Cette commande ne supprime que la configuration par défaut. Il n'installe Policy Controller sur aucun cluster.

Attention : Ne supprimez pas la fonctionnalité de parc Policy Controller et ne désenregistrez pas un cluster tant que la désinstallation de Policy Controller n'est pas terminée. Sinon, Policy Controller continue de s'exécuter sur le cluster sans gestion. N'utilisez pas la commande gcloud container fleet policycontroller detach pour supprimer Policy Controller, car cette commande arrête la gestion et laisse Policy Controller s'exécuter.

Supprimer Policy Controller des clusters en dehors d'un parc

La commande gcloud container fleet policycontroller disable supprime Policy Controller uniquement des clusters gérés par le parc. Un cluster peut exécuter Policy Controller sans gestion de parc dans les cas suivants :

• Vous avez installé Policy Controller à l'aide de l'opérateur ConfigManagement.
• Vous avez annulé l'enregistrement du cluster dans son parc ou exécuté la commande gcloud container fleet policycontroller detach avant que Policy Controller ait terminé la désinstallation.

Pour supprimer Policy Controller de ces clusters, placez-les sous la gestion de parc, puis désinstallez Policy Controller :

1. Sauvegardez vos ConstraintTemplates, vos contraintes, votre configuration de synchronisation et vos mutateurs, comme décrit dans Inventorier et classer vos règles. Lorsque vous nettoyez les métadonnées des sauvegardes effectuées à partir d'une installation de l'opérateur ConfigManagement, supprimez également les libellés configmanagement.gke.io/* et k8s-app: kubernetes-config-management, en plus du champ ownerReferences et des métadonnées policycontroller.*.

2. Si vous avez installé Policy Controller à l'aide de ConfigManagement Operator, supprimez le champ policyController de la ressource personnalisée ConfigManagement sur le cluster. Attendez la fin du rapprochement. Le rapprochement peut prendre environ deux minutes. Vérifiez ensuite si l'espace de noms gatekeeper-system existe toujours :

   kubectl get namespace gatekeeper-system
   

   Dans ConfigManagement Operator version 1.17 et antérieure, la suppression du champ policyController désinstalle automatiquement Policy Controller. Si l'espace de noms gatekeeper-system est introuvable, ignorez les étapes restantes de cette section. Dans ConfigManagement Operator version 1.18 et ultérieure, l'espace de noms gatekeeper-system reste sur le cluster. Passez donc à l'étape suivante.

3. Si le cluster n'est pas enregistré dans un parc, enregistrez-le. Pour en savoir plus, consultez Enregistrer un cluster sur Google Cloud dans votre parc.

4. Vérifiez si la mutation est activée sur le cluster :

   kubectl get mutatingwebhookconfiguration \
       gatekeeper-mutating-webhook-configuration
   

5. Activez Policy Controller sur l'appartenance du cluster afin que le parc prenne en charge la gestion de l'installation existante. Si la commande précédente a renvoyé la ressource gatekeeper-mutating-webhook-configuration, incluez l'option --mutation afin que le parc adopte, puis supprime les ressources de mutation au niveau du cluster :

   gcloud container fleet policycontroller enable \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID
   

   Remplacez les éléments suivants :

   • MEMBERSHIP_NAME : nom d'appartenance de votre cluster enregistré.
   • PROJECT_ID : l'ID de votre projet hôte de parc

6. Attendez que la valeur du champ policycontroller.state de l'appartenance soit ACTIVE :

   gcloud container fleet policycontroller describe \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       --format="yaml(membershipStates)"
   

7. Désinstallez Policy Controller en suivant les étapes de la section Supprimer Policy Controller. Si vous n'installez pas Gatekeeper autogéré, supprimez toutes les CustomResourceDefinitions de contrainte restantes après la suppression de l'espace de noms gatekeeper-system :

   kubectl get crd -o name \
       | grep '\.constraints\.gatekeeper\.sh$' \
       | xargs -r kubectl delete
   

8. Facultatif : Si vous avez enregistré le cluster uniquement pour effectuer cette procédure, annulez son enregistrement une fois que la commande describe affiche l'état NOT_INSTALLED pour l'appartenance. Pour les clusters que vous avez enregistrés à l'aide de l'option --enable-fleet, exécutez la commande gcloud container clusters update avec l'option --clear-fleet-project au lieu de la commande gcloud container fleet memberships unregister. Pour en savoir plus, consultez la section Annuler l'enregistrement d'un cluster.

Étapes suivantes

• Consultez la section Règle d'admission de validation dans la documentation Kubernetes.
• Découvrez comment appliquer des règles de sécurité prédéfinies au niveau du pod à l'aide de PodSecurity.
• Consultez la documentation de Gatekeeper.