Comprendre Azure Policy pour les clusters Kubernetes

Azure Policy étend Gatekeeper v3, un webhook du contrôleur d'admission pour Open Policy Agent (OPA), pour appliquer des contrôles et des protections à grande échelle sur les composants de votre cluster de manière centralisée et cohérente. Les composants de cluster incluent des pods, des conteneurs et des espaces de noms.

Azure Policy permet de gérer et de signaler l’état de conformité de vos composants de cluster Kubernetes à partir d’un emplacement unique. À l'aide du module complémentaire ou de l'extension de Azure Policy, la gestion des composants de votre cluster est améliorée avec des fonctionnalités Azure Policy, telles que la possibilité d'utiliser des selectors et des overrides pour un déploiement et une restauration de stratégie sécurisés.

Azure Policy pour Kubernetes prend en charge les environnements de cluster suivants :

• Azure Kubernetes Service (AKS), via l’extension Add-on d’Azure Policy pour AKS
• Azure Arc activé pour Kubernetes, via Extension d'Azure Policy pour Arc

Vue d’ensemble

En installant le module complémentaire ou l'extension de Azure Policy sur vos clusters Kubernetes, Azure Policy applique les fonctions suivantes :

• Vérifie avec le service Azure Policy les affectations de stratégie relatives au cluster.
• Déploie les définitions de stratégie dans le cluster en tant que modèle de contrainte et ressources personnalisées de contrainte ou en tant que ressource de modèle de mutation (en fonction du contenu de définition de stratégie).
• Signale les détails de l’audit et de la conformité au service Azure Policy.

Pour activer et utiliser Azure Policy avec votre cluster Kubernetes, effectuez les actions suivantes :

1. Configurez votre cluster Kubernetes et installez le module complémentaire Azure Kubernetes Service (AKS) ou l'extension de Azure Policy pour les clusters Kubernetes compatibles avec Arc (en fonction de votre type de cluster).

   Remarque

   Pour connaître les problèmes courants liés à l’installation, consultez Troubleshoot - Azure Policy Module complémentaire.

2. Créer ou utiliser un exemple de définition de Azure Policy pour Kubernetes

3. Affecter une définition à votre cluster Kubernetes

4. Attendre la validation

5. Journalisation et résolution des problèmes

6. Passer en revue les limitations et les recommandations dans notre section FAQ

Installer le module complémentaire Azure Policy pour AKS

Le module complémentaire Azure Policy pour AKS fait partie de Kubernetes version 1.27 avec prise en charge à long terme (LTS).

Prérequis

1. Inscrivez les fournisseurs de ressources et les fonctionnalités en préversion.

   • portail Azure :

     Inscrivez les fournisseurs de ressources Microsoft.PolicyInsights. Pour connaître les étapes, consultez fournisseurs de ressources et types.

   • Azure CLI :

     # Log in first with az login if you're not using Cloud Shell
     
     # Provider register: Register the Azure Policy provider
     az provider register --namespace Microsoft.PolicyInsights
     

2. Vous avez besoin de la Azure CLI version 2.12.0 ou ultérieure installée et configurée. Pour connaître la version de l’interface, exécutez la commande az --version. Si vous devez installer ou mettre à niveau, consultez How to install the Azure CLI.

3. Le cluster AKS doit être une version de Kubernetes prise en charge dans Azure Kubernetes Service (AKS). Utilisez le script suivant pour valider la version de votre cluster AKS :

   # Log in first with az login if you're not using Cloud Shell
   
   # Look for the value in kubernetesVersion
   az aks list
   

4. Ouvrez les ports de l’extension Azure Policy. L’extension Azure Policy utilise ces domaines et ports pour récupérer les définitions de stratégie et les affectations et signaler la conformité du cluster à Azure Policy.

   Domain	Port
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

Une fois les prérequis terminés, installez le module complémentaire Azure Policy dans le cluster AKS que vous souhaitez gérer.

• portail Azure

  1. Lancez le service AKS dans le portail Azure en sélectionnant All services puis en recherchant et en sélectionnant Kubernetes services.

  2. Sélectionnez l’un de vos clusters AKS.

  3. Sélectionnez Stratégies sur le côté gauche de la page du service Kubernetes.

  4. Dans la page principale, sélectionnez le bouton Activer le module complémentaire .

• Azure CLI

  # Log in first with az login if you're not using Cloud Shell
  
  az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
  

Pour vérifier que l’installation du module complémentaire a réussi et que les pods azure-policy et gatekeeper sont en cours d’exécution, exécutez la commande suivante :

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Enfin, vérifiez que le dernier module complémentaire est installé en exécutant cette commande Azure CLI, en remplaçant <rg> par le nom de votre groupe de ressources et <cluster-name> par le nom de votre cluster AKS : az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. Le résultat doit ressembler à la sortie suivante pour les clusters utilisant des principaux de service :

{
  "config": null,
  "enabled": true,
  "identity": null
}

Aussi, la sortie suivante pour les clusters à l'aide de l'identité managée :

 {
   "config": null,
   "enabled": true,
   "identity": {
     "clientId": "########-####-####-####-############",
     "objectId": "########-####-####-####-############",
     "resourceId": "<resource-id>"
   }
 }

Installer l’extension Azure Policy pour Azure Arc Kubernetes activé

Azure Policy pour Kubernetes permet de gérer et de signaler l’état de conformité de vos clusters Kubernetes à partir d’un emplacement unique. Avec l'extension de Azure Policy pour les clusters Kubernetes avec Arc, vous pouvez régir vos composants de cluster Kubernetes avec Arc, tels que les pods et les conteneurs.

Cet article explique comment créer, show extension status et delete l’Azure Policy pour l’extension Kubernetes.

Pour obtenir une vue d’ensemble de la plateforme d’extensions, consultez Azure Arc extensions de cluster.

Prérequis

Si vous avez déjà déployé Azure Policy pour Kubernetes sur un cluster Azure Arc à l’aide de Helm directement sans extensions, suivez les instructions pour delete le graphique Helm. Une fois la suppression effectuée, vous pouvez continuer.

1. Assurez-vous que votre cluster Kubernetes est une distribution prise en charge.

   Remarque

   L'extension Azure Policy pour Arc est prise en charge sur les distributions Kubernetes suivantes.

2. Vérifiez que vous avez rempli toutes les conditions préalables courantes pour les extensions Kubernetes répertoriées here notamment connectant votre cluster à Azure Arc.

   Remarque

   Azure Policy extension est prise en charge pour les clusters Kubernetes avec Arc dans ces régions.

3. Ouvrez les ports de l’extension Azure Policy. L’extension Azure Policy utilise ces domaines et ports pour récupérer les définitions de stratégie et les affectations et signaler la conformité du cluster à Azure Policy.

   Domain	Port
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

4. Avant d’installer l’extension Azure Policy ou d’activer l’une des fonctionnalités du service, votre abonnement doit activer les fournisseurs de ressources Microsoft.PolicyInsights.

   Remarque

   Pour activer le fournisseur de ressources, suivez les étapes décrites dans Resource providers and types ou exécutez la commande Azure CLI ou Azure PowerShell.

   • Azure CLI

     # Log in first with az login if you're not using Cloud Shell
     # Provider register: Register the Azure Policy provider
     az provider register --namespace 'Microsoft.PolicyInsights'
     

   • Azure PowerShell

     # Log in first with Connect-AzAccount if you're not using Cloud Shell
     
     # Provider register: Register the Azure Policy provider
     Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
     

Créer une extension Azure Policy

Pour créer une instance d’extension pour votre cluster avec Arc, exécutez la commande suivante en remplaçant <> par vos valeurs :

az k8s-extension create --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --extension-type Microsoft.PolicyInsights --name <EXTENSION_INSTANCE_NAME>

Exemple :

az k8s-extension create --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --extension-type Microsoft.PolicyInsights --name azurepolicy

Exemple de sortie

{
  "aksAssignedIdentity": null,
  "autoUpgradeMinorVersion": true,
  "configurationProtectedSettings": {},
  "configurationSettings": {},
  "customLocationSettings": null,
  "errorInfo": null,
  "extensionType": "microsoft.policyinsights",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-test-rg/providers/Microsoft.Kubernetes/connectedClusters/my-test-cluster/providers/Microsoft.KubernetesConfiguration/extensions/azurepolicy",
 "identity": {
    "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantId": null,
    "type": "SystemAssigned"
  },
  "location": null,
  "name": "azurepolicy",
  "packageUri": null,
  "provisioningState": "Succeeded",
  "releaseTrain": "Stable",
  "resourceGroup": "my-test-rg",
  "scope": {
    "cluster": {
      "releaseNamespace": "kube-system"
    },
    "namespace": null
  },
  "statuses": [],
  "systemData": {
    "createdAt": "2021-10-27T01:20:06.834236+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2021-10-27T01:20:06.834236+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
  },
  "type": "Microsoft.KubernetesConfiguration/extensions",
  "version": "1.1.0"
}

Afficher l’extension Azure Policy

Pour vérifier la réussite de la création de l’instance d’extension et inspecter ses métadonnées, exécutez la commande suivante en remplaçant <> par vos valeurs :

az k8s-extension show --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Exemple :

az k8s-extension show --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --name azurepolicy

Pour vérifier que l’installation de l’extension a réussi et que les pods azure-policy et gatekeeper sont en cours d’exécution, exécutez la commande suivante :

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Supprimer l’extension Azure Policy

Pour supprimer l’instance d’extension, exécutez la commande suivante en remplaçant <> par vos valeurs :

az k8s-extension delete --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Créer une définition de stratégie

La structure de langage Azure Policy pour la gestion de Kubernetes suit celle des définitions de stratégie existantes. Il existe des exemples de fichiers de définition disponibles pour l'affectation dans la bibliothèque de stratégies intégrée de Azure Policy qui peuvent être utilisés pour régir vos composants de cluster.

Azure Policy pour Kubernetes prend également en charge la création de définitions personnalisées au niveau du composant pour les clusters Azure Kubernetes Service et les clusters Kubernetes compatibles avec Azure Arc. Les exemples de modèles de contrainte et de mutation sont disponibles dans la bibliothèque de la communauté Gatekeeper. L'extension Visual Studio Code d'Azure Policy peut être utilisée pour traduire un modèle de contrainte ou un modèle de mutation existant en définition de stratégie personnalisée pour Azure Policy.

Avec un mode fournisseur Resource de Microsoft.Kubernetes.Data, les effets audit, deny, disabled et mutate sont utilisés pour gérer vos clusters Kubernetes.

Audit et deny doivent fournir des propriétés details spécifiques pour fonctionner avec OPA Constraint Framework et Gatekeeper v3.

Dans le cadre des propriétés details.templateInfo ou details.constraintInfo dans la définition de la stratégie, Azure Policy transmet l’URI ou la valeur Base64Encoded de ces CustomResourceDefinitions (CRD) au module complémentaire. Rego est le langage pris en charge par OPA et Gatekeeper pour valider une requête au cluster Kubernetes. En prenant en charge une norme existante pour la gestion Kubernetes, Azure Policy permet de réutiliser les règles existantes et de les associer à des Azure Policy pour une expérience de création de rapports de conformité cloud unifiée. Pour plus d’informations, consultez Qu’est-ce que Rego ?

Affecter une définition de stratégie

Pour affecter une définition de stratégie à votre cluster Kubernetes, vous devez être affecté aux opérations d'attribution de stratégie appropriées sous le contrôle d'accès basé sur les rôles Azure (Azure RBAC). Les rôles intégrés Azure Contributeur de stratégie de ressource et Propriétaire sont associés à ces opérations. Pour plus d’informations, consultez Autorisations RBAC d'Azure dans Azure Policy.

Recherchez les définitions de stratégie intégrées pour la gestion de votre cluster à l’aide du portail Azure en procédant comme suit. Si vous utilisez une définition de stratégie personnalisée, recherchez-la par son nom ou par la catégorie avec laquelle vous l’avez créée.

1. Démarrez le service Azure Policy dans le portail Azure. Sélectionnez Tous les services dans le volet gauche, puis recherchez et sélectionnez Stratégie.

2. Dans le volet gauche de la page Azure Policy, sélectionnez Definitions.

3. Dans la zone de liste déroulante Catégorie, utilisez Sélectionner tout pour effacer le filtre, puis sélectionnez Kubernetes.

4. Sélectionnez la définition de stratégie, puis sélectionnez le bouton Affecter.

5. Définissez Étendue sur le groupe d’administration, l’abonnement ou le groupe de ressources du cluster Kubernetes auquel s’applique l’affectation de stratégie.

   Remarque

   Lors de l’affectation de la Azure Policy pour la définition Kubernetes, la Scope doit inclure la ressource de cluster.

6. Donnez à l’attribution de stratégie un nom et une description que vous pouvez utiliser pour l’identifier facilement.

7. Définissez l'application de la politique sur l’une des valeurs suivantes :

   • Activé : appliquez la stratégie sur le cluster. Les demandes d’admission Kubernetes avec des violations sont refusées.

   • Désactivé : n’appliquez pas la stratégie sur le cluster. Les demandes d’admission Kubernetes avec des violations ne sont pas refusées. Les résultats de l’évaluation de la conformité sont toujours disponibles. Lorsque vous déployez de nouvelles définitions de stratégie sur des clusters en cours d’exécution, l’option Désactivé est utile pour tester la définition de stratégie en tant que demandes d’admission avec violations ne sont pas refusées.

8. Sélectionnez Suivant.

9. Définir des valeurs de paramètre

   • Pour exclure les espaces de noms Kubernetes de l’évaluation de la stratégie, spécifiez la liste des espaces de noms dans le paramètre Exclusions d'espaces de noms. La recommandation est d’exclure : kube-system, gatekeeper-system et azure-arc.

10. Sélectionnez Vérifier + créer.

Vous pouvez également utiliser le guide de démarrage rapide Affecter une stratégie - Portail pour rechercher et affecter une stratégie Kubernetes. Recherchez une définition de stratégie Kubernetes au lieu des exemples de machines virtuelles d’audit.

Évaluation de la stratégie

Le module complémentaire consulte le service Azure Policy pour les modifications des affectations de stratégies toutes les 15 minutes. Pendant ce cycle d’actualisation, le module complémentaire recherche d’éventuelles modifications, qui déclenchent la création, la mise à jour ou la suppression des modèles de contrainte et des contraintes.

Dans un cluster Kubernetes, si un espace de noms possède une étiquette appropriée au cluster, les demandes d’admission avec violations sont refusées. Les résultats de l’évaluation de la conformité sont toujours disponibles.

• cluster Kubernetes compatible avec Azure Arc : admission.policy.azure.com/ignore

Toutes les quinze minutes, le module complémentaire demande une analyse complète du cluster. Après avoir collecté les détails de l’analyse complète et toutes les évaluations en temps réel par Gatekeeper des tentatives de modification du cluster, le module complémentaire signale les résultats à Azure Policy pour l’inclusion dans les détails de compliance comme n’importe quelle affectation de Azure Policy. Seuls les résultats des affectations de stratégie actives sont renvoyés au cours du cycle d’audit. Les résultats d’audit peuvent également être considérés comme des violations répertoriées dans le champ d’état de la contrainte ayant échoué. Pour plus d’informations sur les ressources non conformes , consultez les détails du composant pour les modes fournisseur de ressources.

Quelques autres considérations :

• Si l’abonnement au cluster est inscrit auprès de Microsoft Defender for Cloud, Microsoft Defender for Cloud stratégies Kubernetes sont appliquées automatiquement sur le cluster.

• Quand une stratégie de refus est appliquée sur un cluster avec des ressources Kubernetes existantes, toute ressource préexistante non conforme à la nouvelle stratégie continue de s’exécuter. Si la ressource non conforme est replanifiée sur un autre nœud, Gatekeeperbloque la création de la ressource.

• Si un cluster comporte une stratégie de refus qui valide les ressources, l’utilisateur ne reçoit pas de message de refus lors de la création d’un déploiement. Prenons l’exemple d’un déploiement Kubernetes qui contient replicasets et des pods. Lorsqu’un utilisateur exécute kubectl describe deployment $MY_DEPLOYMENT, il ne renvoie pas de message de refus dans le cadre des événements. Toutefois, kubectl describe replicasets.apps $MY_DEPLOYMENT retourne les événements associés au rejet.

input_containers[c] {
   c := input.review.object.spec.initContainers[_]
}

Conflits de modèles de contrainte

Si les modèles de contrainte ont le même nom de métadonnées de ressource, mais que la définition de stratégie fait référence à la source à différents emplacements, les définitions de stratégie sont considérées comme étant en conflit. Exemple : deux définitions de stratégie font référence au même fichier template.yaml stocké à différents emplacements sources, tels que le magasin de modèles Azure Policy (store.policy.core.windows.net) et GitHub.

Lorsque des définitions de stratégie et leurs modèles de contrainte sont attribués, mais ne sont pas déjà installés sur le cluster et sont en conflit, ils sont signalés comme un conflit et ne sont pas installés dans le cluster jusqu’à ce que le conflit soit résolu. De même, toutes les définitions de stratégie existantes et leurs modèles de contrainte qui se trouvent déjà sur le cluster en conflit avec les définitions de stratégie nouvellement attribuées continuent de fonctionner normalement. Si une attribution existante est mise à jour et qu’il est impossible de synchroniser le modèle de contrainte, le cluster est également marqué comme un conflit. Pour tous les messages en conflit, consultez les raisons de conformité du mode fournisseur de ressources AKS

Journalisation

En tant que contrôleur/conteneur Kubernetes, les pods azure-policy et gatekeeper conservent les journaux d’activité dans le cluster Kubernetes. En général, les journaux azure-policypeuvent être utilisés pour résoudre les problèmes d’ingestion de stratégie sur le cluster et les rapports de conformité. Les enregistrements pod gatekeeper-controller-manager peuvent être utilisés pour résoudre les problèmes de non-exécution. Les journaux de pod gatekeeper-audit peuvent être utilisés pour résoudre les problèmes d’audit des ressources existantes. Les journaux peuvent être exposés dans la page Insights du cluster Kubernetes. Pour plus d’informations, consultez Surveillez les performances de votre cluster Kubernetes avec Azure Monitor pour les conteneurs.

Pour afficher les journaux du module complémentaire, utilisez kubectl :

# Get the azure-policy pod name installed in kube-system namespace
kubectl logs <azure-policy pod name> -n kube-system

# Get the gatekeeper pod name installed in gatekeeper-system namespace
kubectl logs <gatekeeper pod name> -n gatekeeper-system

Si vous essayez de résoudre les problèmes d’un ComplianceReasonCode particulier qui apparaît dans vos résultats de conformité, vous pouvez rechercher dans les journaux des pods azure-policy pour voir l’erreur complète associée.

Pour plus d’informations, consultez Débogage de Gatekeeper dans la documentation Gatekeeper.

Afficher les artefacts de Gatekeeper

Une fois que le module complémentaire télécharge les affectations de stratégie et installe les modèles de contrainte et les contraintes sur le cluster, il annote les deux avec des informations Azure Policy telles que l’ID d’affectation de stratégie et l’ID de définition de stratégie. Pour configurer votre client afin qu’il puisse afficher les artefacts associés au module complémentaire, procédez comme suit :

1. Configurer kubeconfig pour le cluster.

   Pour un cluster Azure Kubernetes Service, utilisez les Azure CLI suivantes :

   # Set context to the subscription
   az account set --subscription <YOUR-SUBSCRIPTION>
   
   # Save credentials for kubeconfig into .kube in your home folder
   az aks get-credentials --resource-group <RESOURCE-GROUP> --name <CLUSTER-NAME>
   

2. Testez la connexion du cluster.

   Exécutez la commande kubectl cluster-info. Si l’exécution est réussie, chaque service répond avec une URL de l’emplacement où il s’exécute.

Afficher les modèles de contrainte du module complémentaire

Pour afficher les modèles de contrainte téléchargés par le module complémentaire, exécutez kubectl get constrainttemplates. Les modèles de contrainte qui commencent par k8sazure sont ceux installés par le module complémentaire.

Afficher les modèles de mutation du module complémentaire

Pour afficher les modèles de mutation téléchargés par le module complémentaire, exécutez kubectl get assign, kubectl get assignmetadata et kubectl get modifyset.

Obtenir des mappages Azure Policy

Pour identifier le mappage entre un modèle de contrainte téléchargé sur le cluster et la définition de stratégie, utilisez kubectl get constrainttemplates <TEMPLATE> -o yaml. Les résultats ressemblent à la sortie suivante :

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
    annotations:
    azure-policy-definition-id: /subscriptions/<SUBID>/providers/Microsoft.Authorization/policyDefinitions/<GUID>
    constraint-template-installed-by: azure-policy-addon
    constraint-template: <URL-OF-YAML>
    creationTimestamp: "2021-09-01T13:20:55Z"
    generation: 1
    managedFields:
    - apiVersion: templates.gatekeeper.sh/v1beta1
    fieldsType: FieldsV1
...

<SUBID> est l’ID d’abonnement et <GUID> est l’ID de la définition de stratégie mappée. <URL-OF-YAML> est l’emplacement source du modèle de contrainte que le complément a téléchargé pour l’installer sur le cluster.

Afficher les contraintes associées à un modèle de contrainte

Une fois que vous avez les noms des modèles de contrainte téléchargés du module complémentaire, vous pouvez utiliser le nom pour afficher les contraintes associées. Utilisez kubectl get <constraintTemplateName> pour récupérer la liste. Les contraintes installées par le module complémentaire commencent par azurepolicy-.

Afficher les détails de la contrainte

La contrainte contient des détails sur les violations et les mappages à la définition et à l’attribution de la stratégie. Pour afficher les détails, utilisez kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml. Les résultats ressemblent à la sortie suivante :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAzureContainerAllowedImages
metadata:
  annotations:
    azure-policy-assignment-id: /subscriptions/<SUB-ID>/resourceGroups/<RG-NAME>/providers/Microsoft.Authorization/policyAssignments/<ASSIGNMENT-GUID>
    azure-policy-definition-id: /providers/Microsoft.Authorization/policyDefinitions/<DEFINITION-GUID>
    azure-policy-definition-reference-id: ""
    azure-policy-setdefinition-id: ""
    constraint-installed-by: azure-policy-addon
    constraint-url: <URL-OF-YAML>
  creationTimestamp: "2021-09-01T13:20:55Z"
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    - gatekeeper-system
    - azure-arc
  parameters:
    imageRegex: ^.+azurecr.io/.+$
status:
  auditTimestamp: "2021-09-01T13:48:16Z"
  totalViolations: 32
  violations:
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hello-world-78f7bfd5b8-lmc5b
    namespace: default
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hellow-world-89f8bfd6b9-zkggg

Résolution des problèmes liés au module complémentaire

Pour plus d’informations sur la résolution des problèmes liés au module complémentaire pour Kubernetes, consultez la section Kubernetes de l’article de résolution des problèmes Azure Policy.

Pour les problèmes liés à l’extension Azure Policy pour Arc, accédez à :

• Dépannage Kubernetes activé par Azure Arc

Pour les problèmes liés à Azure Policy, consultez :

• Examiner les journaux de la politique Azure
• résolution générale des problèmes pour Azure Policy sur Kubernetes

Azure Policy module complémentaire pour AKS Changelog

Le module complémentaire Azure Policy pour AKS a un numéro de version qui indique la version de l'image du module complémentaire. Comme la prise en charge de la fonctionnalité a été introduite récemment sur le module complémentaire, le numéro de version est augmenté.

Cette section vous aide à identifier la version du module complémentaire installée sur votre cluster et à partager également une table historique de la version du module complémentaire Azure Policy installée par cluster AKS.

Identifier la version du module complémentaire installée sur votre cluster

Le module complémentaire Azure Policy utilise le schéma standard Semantic Versioning pour chaque version. Pour identifier la version du module complémentaire Azure Policy utilisée, vous pouvez exécuter la commande suivante : kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

Pour identifier la version gatekeeper que votre module complémentaire Azure Policy utilise, vous pouvez exécuter la commande suivante : kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

Enfin, pour identifier la version du cluster AKS que vous utilisez, suivez l’aide AKS en lien.

Versions du module complémentaire disponibles pour chaque version de cluster AKS

1.16.1

Présentation de la génération de la stratégie d’admission de validation (VAP). Les stratégies de validation d'admission sont des ressources de validation natives de Kubernetes évaluées dans le processus, permettant une réduction de la latence et une évaluation en mode sécurisé. Les stratégies Azure qui contiennent le Common Expression Language (CEL) génèrent automatiquement des VAP (politiques d'application vérifiées). Pour plus d’informations, consultez la documentation Gatekeeper. Correctif CVE-2026-25679, CVE-2026-27142, CVE-2026-27139 et CVE-2026-32280. Améliorations de sécurité.

• Publication : mai 2026
• Kubernetes : 1.36+
• Gatekeeper : 3.22.1

Gatekeeper 3.22.1

Mise en production de Gatekeeper : https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.22.1 Modifications : https://github.com/open-policy-agent/gatekeeper/compare/v3.20.1...v3.22.1

1.15.5

Améliorations de sécurité.

• Publication : février 2026
• Kubernetes : 1.27+
• Gatekeeper : 3.20.1

1.15.4

Correctif CVE-2025-61727. Améliorations de sécurité.

• Publié : déc. 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.20.1

1.15.3

Correctif CVE-2025-47914, CVE-2025-58181, CVE-2025-58187 et CVE-2025-22872. Améliorations de sécurité.

• Publié : déc. 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.20.1

1.15.1

Améliorations de sécurité.

• Publication : Novembre 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.20.1

1.14.2

Correctif CVE-2025-4802. Améliorations de sécurité.

• Publication : Octobre 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.20.1

Gatekeeper 3.20.1

Mise en production de Gatekeeper : https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.1 Modifications : https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.1

1.13.1

Correctif CVE-2025-47907. Améliorations de sécurité.

• Publication : août 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.20.0

1.13.0

La limite de données de l’UE est désormais prise en charge par Azure Policy pour Kubernetes sur AKS. Pour en savoir plus sur la limite des données de l'UE, consultez : Vue d'ensemble de la limite des données de l'UE. Correctif CVE-2025-22874. Améliorations de sécurité.

• Publication : juillet 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.20.0

Gatekeeper 3.20.0

Mise en production de Gatekeeper : https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.0 Modifications : https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.0

1.12.3

Patch CVE-2025-22874 et GHSA-vrw8-fxc6-2r93. Améliorations de sécurité.

• Publication : juillet 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.19.1

1.12.2

Améliorations de sécurité.

• Publication : juin 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.19.1

1.11.1

Correctif CVE-2025-22872. Améliorations de sécurité.

• Publication : mai 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.19.1

Gatekeeper 3.19.1

Mise en production de Gatekeeper : https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.19.1 Modifications : https://github.com/open-policy-agent/gatekeeper/compare/v3.18.2...v3.19.1

1.10.1

Correctif CVE-2025-30204 et CVE-2025-22870. Améliorations de sécurité.

• Publication : avril 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.18.2

1.10.0

CEL est activé par défaut, vous pouvez continuer à utiliser Rego. Le nouveau CRD configpodstatuses.status.gatekeeper.sh est introduit (Référence : https://github.com/open-policy-agent/gatekeeper/issues/2918). Améliorations de sécurité.

• Publication : février 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.18.2

Gatekeeper 3.18.2

Mise en production de Gatekeeper : https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.18.2 Modifications : https://github.com/open-policy-agent/gatekeeper/compare/v3.17.1...v3.18.2

1.9.1

Correctif CVE-2024-45337 et CVE-2024-45338. Améliorations de sécurité.

• Publication : janvier 2025
• Kubernetes : 1.27+
• Gatekeeper : 3.17.1

Gatekeeper 3.17.1

Mise en production de Gatekeeper : https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.17.1

1.8.0

La stratégie peut désormais être utilisée pour évaluer les opérations CONNECT, par exemple pour refuser des exec. Notez qu’il n’existe pas de conformité « brownfield » disponible pour les opérations CONNECT non conformes : une stratégie avec un effet d’audit ciblant des CONNECT ne produit pas de résultat. Améliorations de sécurité.

• Publication : novembre 2024
• Kubernetes : 1.27+
• Gatekeeper : 3.17.1

1.7.1

Présentation de CEL et VAP. Common Expression Language (CEL) est un langage d’expression natif Kubernetes qui peut être utilisé pour déclarer des règles de validation d’une stratégie. La validation de la fonctionnalité de stratégie d’admission (VAP) fournit une évaluation de stratégie dans l’arborescence, réduit la latence des requêtes d’admission et améliore la fiabilité et la disponibilité. Les actions de validation prises en charge incluent Deny, Warn et Audit. La création de stratégies personnalisées pour CEL/VAP est autorisée et les utilisateurs existants n’ont pas besoin de convertir leur Rego en CEL, car ils seront tous les deux pris en charge et utilisés pour appliquer des stratégies. Pour utiliser CEL et VAP, les utilisateurs doivent s’inscrire à l’indicateur de fonctionnalité AKS-AzurePolicyK8sNativeValidation dans l’espace de noms Microsoft.ContainerService. Pour plus d’informations, consultez la documentation Gatekeeper. Améliorations de sécurité.

• Publication : septembre 2024
• Kubernetes : 1.27+ (la génération VAP n’est prise en charge que sur la version 1.30+)
• Gatekeeper : 3.17.1

1.7.0

Présentation de l’extension, fonctionnalité de déplacement vers la gauche qui vous permet de savoir si vos ressources de charge de travail (Déploiements, ReplicaSets, Tâches, etc.) produisent des pods admissibles. L’extension ne doit pas modifier le comportement de vos stratégies ; elle déplace simplement l’évaluation des stratégies étendues aux pods par l’opérateur de contrôle d'appels au moment de l’admission de la charge de travail plutôt qu’au moment de l’admission des pods. Toutefois, pour effectuer cette évaluation, elle doit générer et évaluer un pod de simulation basé sur la spécification de pod définie dans la charge de travail, laquelle peut avoir des métadonnées incomplètes. Par exemple, le pod de simulation ne contient pas les références de propriétaire appropriées. En raison de ce petit risque de modification du comportement de la stratégie, nous proposons l’extension comme désactivée par défaut. Pour activer l’extension pour une définition de stratégie donnée, définissez .policyRule.then.details.source sur All. Les éléments intégrés seront bientôt mis à jour pour permettre le paramétrage de ce champ. Si vous testez votre définition de stratégie et que le pod de simulation généré à des fins d’évaluation est incomplet, vous pouvez également utiliser une mutation avec Generated comme source pour muter les pods de simulation. Pour plus d’informations sur cette option, consultez la documentation Gatekeeper. L’extension est actuellement disponible seulement sur les clusters AKS, et non pas sur les clusters Arc. Améliorations de sécurité.

• Publication : juillet 2024
• Kubernetes : 1.27+
• Gatekeeper : 3.16.3

1.6.1

Améliorations de sécurité.

• Publication : mai 2024
• Gatekeeper : 3.14.2

1.5.0

Améliorations de sécurité.

• Publication : mai 2024
• Kubernetes : 1.27+
• Gatekeeper : 3.16.3

1.4.0

Active les données de mutation et les données externes par défaut. Le webhook de mutation supplémentaire et la limite du délai d’expiration du webhook de validation peuvent dans le pire des cas ajouter de la latence aux appels. Introduit également la prise en charge de l’affichage de la définition de stratégie et de la version de définition de l’ensemble dans les résultats de conformité. Améliorations de sécurité.

• Publication : mai 2024
• Kubernetes : 1.25+
• Gatekeeper : 3.14.0

1.3.0

Introduit l’état d’erreur des stratégies en erreur, ce qui leur permet d’être distingués des stratégies dans des états non conformes. Ajoute la prise en charge des modèles de contrainte v1 et l’utilisation du paramètre excludedNamespaces dans les politiques de mutation. Ajoute une vérification de l’état d’erreur sur les modèles de contrainte après l’installation. Améliorations de sécurité.

• Publication : février 2024
• Kubernetes : 1.25+
• Gatekeeper : 3.14.0

1.2.1

Améliorations de sécurité.

• Publication : octobre 2023
• Kubernetes : 1.25+
• Gatekeeper : 3.13.3

1.1.0

Améliorations de sécurité.

• Publication : juillet 2023
• Kubernetes : 1.27+
• Gatekeeper : 3.11.1

1.0.1

Améliorations de sécurité.

• Publication : juin 2023
• Kubernetes : 1.24+
• Gatekeeper : 3.11.1

1.0.0

Azure Policy pour Kubernetes prend désormais en charge la mutation pour corriger les clusters AKS à grande échelle.

Supprimer le module complémentaire

Supprimer le module complémentaire d’AKS

Pour supprimer le module complémentaire Azure Policy de votre cluster AKS, utilisez le portail Azure ou Azure CLI :

• portail Azure

  1. Lancez le service AKS dans le portail Azure en sélectionnant All services puis en recherchant et en sélectionnant Kubernetes services.

  2. Sélectionnez votre cluster AKS dans lequel vous souhaitez désactiver le module complémentaire Azure Policy.

  3. Sélectionnez Stratégies sur le côté gauche de la page du service Kubernetes.

  4. Dans la page principale, sélectionnez le bouton Désactiver le module complémentaire .

• Azure CLI

  # Log in first with az login if you're not using Cloud Shell
  
  az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
  

Supprimer le module complémentaire de Kubernetes activé par Azure Arc

Pour supprimer le module complémentaire Azure Policy et Gatekeeper de votre cluster Kubernetes Azure Arc activé, exécutez la commande Helm suivante :

helm uninstall azure-policy-addon

Supprimer le module complémentaire du moteur AKS

Pour supprimer le module complémentaire Azure Policy et Gatekeeper de votre cluster AKS Engine, utilisez la méthode qui s’aligne sur la façon dont le module complémentaire a été installé :

• Si elle est installée en définissant la propriété addons dans la définition de cluster pour le moteur AKS :

  Redéployez la définition du cluster sur le moteur AKS après avoir modifié la propriété de modules complémentaires pour azure-policy à false :

  "addons": [
    {
      "name": "azure-policy",
      "enabled": false
    }
  ]
  

  Pour plus d’informations, consultez AKS Engine - Disable Azure Policy Add-on.

• S’il a été installé avec des graphiques Helm, exécutez la commande Helm suivante :

  helm uninstall azure-policy-addon
  

Limites

• Pour connaître les limites générales des Azure Policy et des affectations, passez en revue les limites documentées de Azure Policy
• Azure Policy add-on pour Kubernetes ne peut être déployé que sur des groupes de nœuds Linux.
• Nombre maximal de pods pris en charge par le module complémentaire Azure Policy par cluster : 10 000
• Nombre maximal d’enregistrements non conformes par stratégie par cluster : 500
• Nombre maximal d’enregistrements non conformes par abonnement : 1 million
• Les raisons de la non-conformité ne sont pas disponibles pour le fournisseur de ressources en mode Microsoft.Kubernetes.Data. Utilisez les détails du composant.
• Les exemptions au niveau du composant ne sont pas prises en charge pour les modes fournisseur de ressources. La prise en charge des paramètres est disponible dans les définitions de la stratégie Azure pour exclure et inclure des espaces de noms particuliers.
• L’utilisation de l’annotation metadata.gatekeeper.sh/requires-sync-data dans un modèle de contrainte pour configurer la réplication des données de votre cluster dans le cache OPA n’est actuellement autorisée que pour les stratégies intégrées. La raison en est qu’elle peut augmenter considérablement l’utilisation des ressources des pods Gatekeeper si elle n’est pas utilisée avec attention.

Définition de la configuration Gatekeeper

La modification de la configuration Gatekeeper n’est pas prise en charge, car elle contient des paramètres de sécurité critiques. Les modifications apportées à la configuration sont rapprochées.

Utilisation de data.inventory dans des modèles de contrainte

Actuellement, plusieurs stratégies intégrées utilisent la réplication des données, ce qui permet aux utilisateurs de synchroniser les ressources sur cluster existantes avec le cache OPA et de les référencer lors de l’évaluation d’une AdmissionReview demande. Les stratégies de réplication des données peuvent être différenciées par la présence de data.inventory dans le Rego, et la présence de l’annotation metadata.gatekeeper.sh/requires-sync-data, indiquant au module complémentaire Azure Policy quelles ressources doivent être mises en cache pour que l'évaluation de la politique fonctionne correctement. Ce processus diffère de celui de Gatekeeper autonome, où cette annotation est descriptive et non prescriptive.

La réplication des données est actuellement bloquée pour une utilisation dans les définitions de stratégie personnalisées, car la réplication des ressources avec des nombres d’instances élevés peut augmenter considérablement l’utilisation des ressources des pods Gatekeeper si elle n’est pas utilisée avec attention. Vous voyez une erreur ConstraintTemplateInstallFailed quand vous tentez de créer une définition de stratégie personnalisée contenant un modèle de contrainte avec cette annotation.

La suppression de l’annotation peut sembler atténuer l’erreur que vous voyez, mais le module complémentaire de stratégie ne synchronise aucune ressource requise pour ce modèle de contrainte dans le cache. Par conséquent, vos stratégies sont évaluées par rapport à un data.inventory vide (en supposant qu’aucun composant intégré n’est attribué qui réplique les ressources requises). Cela fournira des résultats de conformité trompeurs. Comme indiqué précédemment, la modification manuelle de la configuration pour mettre en cache les ressources requises n’est pas également autorisée.

Les limitations suivantes s’appliquent uniquement au module complémentaire Azure Policy pour AKS :

• La stratégie de sécurité des pods AKS et le module complémentaire Azure Policy pour AKS ne peuvent pas être activés. Pour plus d’informations, consultez la limitation de sécurité des pods AKS.
• Espaces de noms automatiquement exclus par l'add-on Azure Policy pour l’évaluation : kube-system et gatekeeper-system.

Forum aux questions

Que déploie l'extension Azure Policy / l'add-on Azure Policy sur mon cluster lors de l'installation ?

Le module complémentaire Azure Policy nécessite trois composants Gatekeeper pour s’exécuter : un pod d’audit et deux réplicas de pod webhook. Un pod Azure Policy et un pod webhook Azure Policy sont également installés.

Quelle consommation de ressources dois-je attendre que le module complémentaire /extension Azure Policy utilise sur chaque cluster ?

Les Azure Policy pour les composants Kubernetes qui s’exécutent sur votre cluster consomment davantage de ressources à mesure que le nombre de ressources Kubernetes et d’affectations de stratégie augmente dans le cluster, ce qui nécessite des opérations d’audit et d’application.

Voici des estimations pour vous aider à planifier :

• Pour moins de 500 pods dans un seul cluster avec un maximum de 20 contraintes : 2 processeurs virtuels et 350 Mo de mémoire par composant.
• Pour plus de 500 pods dans un seul cluster avec un maximum de 40 contraintes : 3 processeurs virtuels et 600 Mo de mémoire par composant.

Peut-on appliquer Azure Policy pour les définitions Kubernetes sur des pods Windows ?

Windows pods ne prennent pas en charge les contextes de sécurité. Par conséquent, certaines des définitions Azure Policy, telles que le refus des niveaux de privilèges root, ne peuvent pas être escaladées dans les pods Windows et s'appliquent uniquement aux pods Linux.

Quel type de données de diagnostic sont collectées par l'extension Azure Policy ?

Le module complémentaire Azure Policy pour Kubernetes collecte des données de diagnostic de cluster limitées. Ces données de diagnostic sont des données techniques vitales concernant les logiciels et le niveau de performance. Les données sont utilisées des façons suivantes :

• Conservez le module complémentaire Azure Policy à jour.
• Gardez Azure Policy module complémentaire sécurisé, fiable et performant.
• Améliorez l'extension Azure Policy grâce à l'analyse agrégée de son utilisation.

Les informations collectées par le module complémentaire ne sont pas des données personnelles. Les détails suivants sont actuellement recueillis :

• Version de l'agent complémentaire Azure Policy
• Type de cluster
• Région du cluster
• Groupe de ressources de cluster
• ID de la ressource de cluster
• ID de l’abonnement du cluster
• Système d’exploitation du cluster (exemple : Linux)
• Ville du cluster (exemple : Seattle)
• État ou province du cluster (exemple : Washington)
• Pays ou région du cluster (exemple : États-Unis)
• Exceptions/erreurs rencontrées par le module complémentaire de Azure Policy pendant l’installation de l’agent lors de l’évaluation de la stratégie
• Nombre de définitions de stratégies Gatekeeper non installées par le module Azure Policy Add-on

Quelles sont les meilleures pratiques générales à garder à l’esprit lors de l’installation du module complémentaire Azure Policy ?

• Utilisez le pool de nœuds système avec la teinte CriticalAddonsOnly pour planifier des pods Gatekeeper. Pour plus d’informations, consultez Utilisation des pools de nœuds système.
• Sécurisez le trafic sortant de vos clusters AKS. Pour plus d’informations, consultez Contrôler le trafic de sortie pour les nœuds de cluster.
• Si le cluster a aad-pod-identity activé, les pods NMI (Node Managed Identity) modifient les nœuds iptables pour intercepter les appels au point de terminaison de métadonnées de l’instance Azure. Cette configuration signifie que toutes les requêtes adressées au point de terminaison Metadata sont interceptées par NMI, même si le pod n’utilise pas aad-pod-identity.
• Vous pouvez configurer la CRD AzurePodIdentityException pour informer aad-pod-identity que toutes les requêtes adressées au point de terminaison de métadonnées depuis un pod correspondant aux étiquettes définies dans la CRD doivent être proxisées sans aucun traitement dans NMI. Vous devez exclure de kubernetes.azure.com/managedby: aks les pods système ayant l’étiquette aad-pod-identity dans l’espace de noms kube-system en configurant la CRD AzurePodIdentityException. Pour plus d’informations, consultez Désactiver l’identité aad-pod pour un pod ou une application spécifique. Pour configurer une exception, installez la mic-exception YAML.

Étapes suivantes

• Passez en revue les exemples Azure Policy.
• Passez en revue la structure de définition de stratégie.
• Passez en revue Comprendre les effets des politiques.
• Découvrez comment créer des stratégies par programmation.
• Découvrez comment obtenir des données de conformité.
• Découvrez comment corriger les ressources non conformes.
• Passez en revue ce qu’est un groupe d’administration avec Organiser vos ressources avec des groupes d’administration Azure.