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

10 minutes

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 sont autorisés à utiliser les logiciels, le matériel et d’autres ressources dans l’organisation. Par conséquent, les entreprises utilisent des stratégies pour appliquer, examiner et définir l’accès. 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 avec des stratégies. 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. Vous décidez d’utiliser Azure Policy pour appliquer l’idée sur vos ressources cloud Azure.

Avant de voir comment utiliser Azure Policy pour Kubernetes, vous devez comprendre 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. Les contrôleurs d’admission doivent être configurés au moment de l’exécution. Ces contrôleurs d’admission existent soit pour votre plug-in d’admission compilé, soit sous la forme d’une extension déployée s’exécutant comme un webhook.

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) qui suit la syntaxe OPA.

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

Utilisez l’OPA Gatekeeper pour définir des stratégies applicables à l’ensemble de l’organisation avec des règles :

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.
La convention d’affectation de noms des étiquettes pour tous les espaces de noms dans un cluster doivent spécifier un point de contact pour chaque espace de noms.
Mandat que les services de cluster ont des sélecteurs globaux uniques.

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. Nous fournissons ici des exemples, mais vous allez effectuer les étapes dans l’unité suivante.

Inscrivez deux fournisseurs de ressources à l’aide de la commande az provider register :
- Microsoft.ContainerService et Microsoft.PolicyInsights : Ces fournisseurs de ressources prend en charge des actions telles que l’interrogation des informations relatives aux événements de stratégie et à la gestion des conteneurs. Il s’agit d’actions pour interroger, créer, mettre à jour ou supprimer une correction de stratégie.
Voici un exemple des deux commandes d’inscription :
```
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.PolicyInsights
```
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
```
Après avoir vérifié que l’inscription de la fonctionnalité a abouti, exécutez la commande az provider register avec le paramètre --namespace pour propager l’inscription de la nouvelle fonctionnalité. Voici un exemple de la commande :
```
az provider register -n Microsoft.ContainerService
```
Activez le module complémentaire azure-policy :
```
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, qui contient le azure-policy et azure-policy-webhook. Le second espace de noms est gatekeeper-system, qui contient le 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, votre webhook de stratégie peut autoriser ou refuser 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	Exemple
Nom	Nom de la stratégie.	[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.
Portée	Groupe de ressources d’abonnement auquel cette stratégie s’applique.	mySubscription/rg-akscostsaving.
État de conformité	État des stratégies attribuées.	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.	100
Ressources non conformes	Nombre de ressources uniques qui enfreignent une ou plusieurs règles de stratégie.	3
Stratégies non conformes	Nombre de stratégies non conformes.	5

À partir de là, vous explorez les détails par ressource et par stratégie pour 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

Pour attribuer une stratégie, sélectionnez l’option Attributions dans la section Création du volet de navigation d’Azure Policy.

Vous affectez des stratégies Azure de deux façons : en tant que groupe de stratégies, appelé une 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 configurables lorsque vous attribuez 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. Ce tableau répertorie les éléments que vous pouvez configurer :

Élément	Description
Portée	L’étendue détermine les ressources ou le groupe de ressources auxquels l’attribution de stratégie est appliquée. 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 utilisé pour identifier la stratégie attribuée.
Description	Description en texte libre de la stratégie.
Application de la stratégie	Vous pouvez choisir Activé ou Désactivé. 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. Vous pouvez 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. Ce paramètre active ou désactive l’exécution de la stratégie. À 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 la valeur auditer, refuser ou désactiver 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 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 enfreignent la nouvelle stratégie. Par défaut, seules les ressources nouvellement créées sont appliqués à la nouvelle stratégie. Utilisez la correction pour case activée ressources existantes après avoir affecté une nouvelle stratégie. Les tâches de correction peuvent varier selon les types de stratégies appliquées.

Dans l’exercice suivant, vous utilisez 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 pour d’avantage baisser les coûts.