Configurer des stratégies de quota de ressources AKS à l’aide d’Azure Policy pour Kubernetes

Azure Policy vous aide à appliquer les normes et à évaluer la conformité à grand échelle pour votre environnement cloud. Il est conseillé aux entreprises d’implémenter des règles d’entreprise pour définir la manière dont les employés peuvent utiliser les logiciels, le matériel et d’autres ressources dans l’organisation. Ces règles d’entreprise sont souvent décrites à l’aide de stratégies mises en place, appliquées et révisées conformément à la définition de chaque stratégie. Une stratégie permet à une organisation de respecter les exigences de gouvernance et légales, ainsi que d’implémenter les meilleures pratiques et d’établir des conventions organisationnelles.

Azure Kubernetes Service (AKS) vous permet d’orchestrer efficacement vos applications natives cloud. Cette facilité a permis à d’autres équipes de développement de votre entreprise d’adopter AKS en tant que plateforme de développement. Vous réalisez que vous devez appliquer des règles d’entreprise pour gérer la façon dont les équipes utilisent AKS afin de garantir une approche rentable de la création des charges de travail. Vous pouvez utiliser Azure Policy pour appliquer la même idée à la façon dont vos ressources cloud Azure sont utilisées.

Avant d’aborder la manière d’utiliser Azure Policy pour Kubernetes, nous devons passer en revue quelques concepts supplémentaires en lien avec cette fonctionnalité dans Kubernetes.

Qu’est-ce qu’un contrôleur d’admission Kubernetes ?

Un contrôleur d’admission est un plug-in Kubernetes qui intercepte les demandes authentifiées et autorisées adressées à l’API Kubernetes avant la persistance de l’objet Kubernetes demandé. Par exemple, supposons que vous déployez une nouvelle charge de travail et que ce déploiement inclut une demande de pod avec des exigences de mémoire spécifiques. Le contrôleur d’admission intercepte la demande de déploiement et doit autoriser le déploiement avant qu’il ne persiste sur le cluster.

Vous pouvez considérer un contrôleur d’admission comme un logiciel qui régit et applique la manière dont le cluster est utilisé et conçu. Il limite les demandes de création, de suppression et de modification d’objets Kubernetes.

Qu’est-ce qu’un webhook de contrôleur d’admission ?

Un webhook de contrôleur d’admission est une fonction de rappel HTTP qui reçoit des demandes d’admission, puis agit sur celles-ci. Des contrôleurs d’admission existent sous une forme compilée dans un plug-in d’admission, ou sous la forme d’une extension déployée s’exécutant comme un webhook que vous configurez au moment de l’exécution.

Il existe deux types de webhooks d’admission : les webhooks de validation et les webhooks de mutation. Un webhook de mutation est appelé en premier, qui peut modifier et appliquer des valeurs par défaut sur les objets envoyés au serveur d’API. Un webhook de validation valide les valeurs d’objets et peut rejeter des demandes.

Qu’est-ce que l’agent de stratégie ouverte (OPA, Open Policy Agent) ?

L’agent de stratégie ouverte (OPA) est un moteur de stratégie open source à usage général qui vous offre un langage déclaratif de haut niveau pour créer des stratégies. Ces stratégies vous permettent de définir des règles qui supervisent le comportement de votre système.

Qu’est-ce que l’OPA Gatekeeper ?

L’OPA Gatekeeper est un webhook de contrôleur d’admission Kubernetes de validation open source qui applique des stratégies basées sur une définition de ressource personnalisée (CRD, Custom Resource Definition) en utilisant l’OPA.

L’objectif de l’OPA Gatekeeper est de vous permettre de personnaliser des stratégies d’admission en utilisant une configuration plutôt que des règles de stratégie codées en dur pour les services. Il offre également une vue complète de votre cluster pour identifier les ressources qui violent la stratégie.

Vous pouvez utiliser l’OPA Gatekeeper pour définir des stratégies applicables à l’ensemble de l’organisation. Par exemple, vous pouvez imposer les exigences suivantes :

  • Des limites de ressources maximales, telles que des limites de processeur et de mémoire, appliquées à tous les pods configurés.

  • Le déploiement d’images est autorisé uniquement à partir de référentiels approuvés.

  • Des étiquettes pour tous les espaces de noms dans un cluster spécifient un point de contact pour chaque espace de noms.

  • Les services de cluster ont des sélecteurs globaux uniques.

La version actuelle de l’OPA Gatekeeper (version 3) est prise en charge par Azure Kubernetes Service.

Azure Policy pour AKS

Azure Policy étend la version 3 de l’OPA Gatekeeper et s’intègre à AKS via des stratégies intégrées. Ces stratégies appliquent à grande échelle des exécutions et des protections à votre cluster de manière centralisée et cohérente.

Les équipes de développement de votre entreprise veulent optimiser le développement et introduire des outils de développement tels que DevSpaces pour simplifier leur flux de travail de développement Kubernetes. Vous tenez à vous assurer que les membres de l’équipe respectent des limites de ressources spécifiques pour leurs projets. Vous décidez de mettre en place une stratégie qui définit les ressources de calcul, les ressources de stockage et le nombre d’objets autorisés dans les espaces de noms de développement.

Pour établir des limites de ressources, vous pouvez appliquer des quotas de ressources au niveau de l’espace de noms et surveiller l’utilisation des ressources pour ajuster les quotas de la stratégie. Utilisez cette stratégie pour réserver et limiter les ressources disponibles au sein de l’équipe de développement.

Activer le module complémentaire Azure Policy pour AKS

Il existe quelques étapes à suivre pour inscrire la fonctionnalité de Module complémentaire Azure Policy pour AKS.

Attention

À l’instar des nœuds spot, le Module complémentaire Azure Policy pour AKS est une fonctionnalité d'évaluation. Après avoir activé certaines fonctionnalités d’évaluation dans Azure, les valeurs par défaut peuvent être utilisées pour tous les clusters AKS créés dans l’abonnement. Testez les fonctionnalités d’évaluation dans des abonnements hors production pour éviter des effets secondaires imprévus dans les déploiements de production.

  1. Inscrivez deux fournisseurs de ressources à l’aide de la commande az provider register :

    • Microsoft.ContainerService : Ce fournisseur de ressources est le même que celui que vous avez utilisé pour inscrire la fonctionnalité spotpoolpreview précédemment.

    • Microsoft.PolicyInsights : Ce fournisseur de ressources prend en charge des actions telles que l’interrogation des informations relatives aux événements de stratégie. Il permet également d’interroger, de créer ou de mettre à jour et de supprimer la correction de stratégie.

    Voici un exemple des deux commandes d’inscription :

    az provider register --namespace Microsoft.ContainerService
    az provider register --namespace Microsoft.PolicyInsights
    
  2. Inscrivez la fonctionnalité AKS-AzurePolicyAutoApprove auprès du fournisseur de ressources Microsoft. ContainerService. Voici un exemple de la commande :

    az feature register --namespace Microsoft.ContainerService --name AKS-AzurePolicyAutoApprove
    
  3. Après vous être assuré que l’inscription de la fonctionnalité a abouti, vous devez exécuter la commande az provider register avec le paramètre --namespace pour propager la nouvelle inscription de la fonctionnalité. Voici un exemple de la commande :

    az provider register -n Microsoft.ContainerService
    
  4. Installer l’extension Azure CLI en préversion et activez le module complémentaire Azure Policy. Utilisez la commande az extensions add, puis activez le module complémentaire azure-policy à l’aide de la commande az aks enable-addons.

    Voici un exemple des deux commandes :

    az extension add --name aks-preview
    
    az aks enable-addons \
        --addons azure-policy \
        --name myAKSCluster \
        --resource-group myResourceGroup
    

    L’activation du module complémentaire a pour effet de planifier des charges de travail dans deux espaces de noms sur votre cluster. Le premier espace de noms est kube-system, où vous trouverez azure-policy et azure-policy-webhook. Le second espace de noms est gatekeeper-system, où vous trouverez gatekeeper-controller-manager. Ces charges de travail sont responsable de l’évaluation des demandes soumises au plan de contrôle AKS. En fonction de vos stratégies configurées, le webhook de stratégie autorise ou refuse des demandes.

Affecter une définition de stratégie intégrée

Vous gérez les stratégies de votre environnement Azure à l’aide du tableau de bord de conformité Azure Policy. Le tableau de bord vous permet de descendre dans la hiérarchie à un niveau de détail par ressource et par stratégie. Il vous aide à mettre vos ressources en conformité à l’aide d’une correction en bloc des ressources existantes et d’une correction automatique pour de nouvelles ressources.

Pour chaque stratégie, les informations suivantes sont présentées :

Élément Description
Nom Nom de la stratégie. Par exemple, [Préversion] : Veiller à ce que les limites de ressources de processeur et de mémoire sur les conteneurs ne dépassent pas les limites spécifiées dans le cluster Kubernetes.
Étendue Groupe de ressources d’abonnement auquel cette stratégie s’applique. Par exemple, "Visual Studio Enterprise/rg-akscostsaving".
État de conformité État des stratégies attribuées. La valeur peut être Réclamation, En conflit, Non démarrée ou Non inscrite.
Conformité des ressources Pourcentage des ressources conformes à la stratégie. Ce calcul prend en compte les ressources conformes, non conformes et en conflit.
Ressources non conformes Nombre de ressources uniques qui enfreignent une ou plusieurs règles de stratégie.
Stratégies non conformes Nombre de stratégies non conformes.

À partir de là, vous explorez les détails par ressource et par stratégie, ainsi que les événements déclenchés. Par exemple, vous pouvez examiner les détails d’un déploiement de charge de travail refusé.

Attribution de stratégies

Des stratégies Azure sont attribuées. Pour attribuer une stratégie, vous devez sélectionner l’option Attributions dans la section Création du volet de navigation d’Azure Policy.

Vous attribuez des stratégies Azure de deux manières : en tant que groupe de stratégies, appelé initiative, ou en tant que stratégie unique.

Attribution d’initiative

Une attribution d’initiative est une collection de définitions de stratégie Azure regroupées pour atteindre un objectif. Par exemple, cet objectif peut consister à appliquer la norme PCI DSS (Payment Card Industry Data Security Standard) à vos ressources.

Attribution de stratégie

Une attribution de stratégie attribue une stratégie unique, par exemple Ne pas autoriser les conteneurs privilégiés dans un cluster Kubernetes.

Attribuer une stratégie

Chaque stratégie est définie à l’aide d’une série d’étapes de configuration. La quantité d’informations que vous capturez dépend du type de stratégie que vous sélectionnez.

Par exemple, pour limiter le déploiement de ressources par les développeurs dans l’environnement cloud de l’entreprise, vous pouvez attribuer l’une des stratégies Azure intégrées pour Azure Kubernetes Service. Le nom de la stratégie est Veiller à ce que les limites de ressources de processeur et de mémoire sur les conteneurs ne dépassent pas les limites spécifiées dans le cluster Kubernetes.

La stratégie exige que vous définissiez la limite des ressources autorisées visées par les demandes de déploiement.

Examinons les options que vous configurez pour attribuer une stratégie.

Informations sur la stratégie de base

La première étape implique la sélection et l’entrée des informations de base qui définissent la nouvelle stratégie. Par exemple, ces informations peuvent porter sur la stratégie et l’étendue de ressource couverte par la stratégie. Ce tableau répertorie les éléments que vous allez configurer :

Élément Description
Étendue Une étendue détermine les ressources ou le groupe de ressources auxquels l’attribution de stratégie s’applique. Cette valeur est basée sur un abonnement ou un groupe d’administration. Vous pouvez exclure des ressources de votre sélection à un niveau inférieur au niveau de l’étendue.
Définition de stratégie Stratégie que vous souhaitez appliquer. Vous pouvez choisir parmi plusieurs options de stratégie intégrées.
Nom de l’attribution Nom identifiant la stratégie attribuée.
Description Description en texte libre de la stratégie.
Application de la stratégie Cette option bascule entre Activée et Désactivée. Si l’option est Désactivée, la stratégie n’est pas appliquée et les demandes ne sont pas refusées avec une non-conformité.
Attribuée par Valeur de texte libre qui correspond par défaut à l’utilisateur inscrit. Il n'est pas possible de modifier cette valeur.

Paramètres de stratégie

Les stratégies exigent que vous configuriez des règles d’entreprise s’appliquant à chaque stratégie spécifique. Toutes les stratégies ne sont pas régies par les mêmes règles d’entreprise. Chacune présente des paramètres distincts.

Par exemple, la stratégie Veiller à ce que les limites de ressources de processeur et de mémoire sur les conteneurs ne dépassent pas les limites spécifiées dans le cluster Kubernetes requiert que vous définissiez trois paramètres :

  • Nombre maximal d’unités de processeur autorisées pour un conteneur.
  • Nombre maximal d’octets de mémoire autorisés pour un conteneur.
  • Liste d’espaces de noms Kubernetes à exclure de la stratégie.

Comparez cette stratégie à la stratégie L’application web doit uniquement être accessible via HTTPS, qui n’inclut pas de paramètres personnalisés à configurer.

Toutes les stratégies ont un paramètre Effet. Celui-ci active ou désactive leur exécution. À l’instar des paramètres, les stratégies peuvent également présenter différentes options Effet.

Par exemple, pour la stratégie de gestion des ressources, vous pouvez sélectionner Audit, Deny ou Disable pour Effet. Pour la stratégie d’application web, vous pouvez uniquement sélectionner Audit ou Disable.

Ce tableau répertorie tous les effets actuellement pris en charge dans les définitions de stratégie :

Effet Description
Append Ajoute des champs supplémentaire à la ressource demandée.
Audit Crée un événement d’avertissement dans le journal d’activité.
AuditIfNotExists Active l’audit des ressources associées à la ressource qui correspond à la condition.
Deny Empêche une demande de ressource qui ne correspond pas aux normes spécifiées dans une définition de stratégie et qui fait échouer la demande.
DeployIfNotExists Exécute un déploiement de modèle quand la condition est remplie.
Disabled Utile dans des situations de test ou lorsque la définition de stratégie a paramétré l’effet et que vous souhaitez désactiver une seule attribution.
Modify Ajoute, met à jour ou supprime des étiquettes sur une ressource lors de sa création ou de sa mise à jour.

Correction de stratégie

L’étape finale consiste à considérer la correction de stratégie. Lorsque vous attribuez des stratégies, il est possible que des ressources existent déjà et qu’elles soient concernées par la nouvelle stratégie. Par défaut, seules les ressources nouvellement créées sont affectées par la nouvelle stratégie. Vous pouvez mettre à jour des ressources existantes à l’aide d’une tâche de correction après avoir attribué la stratégie. Les tâches de correction varient selon les types de stratégies appliquées.

Dans l’exercice suivant, attribuons la stratégie Veiller à ce que les limites de ressources de processeur et de mémoire sur les conteneurs ne dépassent pas les limites spécifiées dans le cluster Kubernetes.